PRACH TRANSMISSION METHODS FOR TIME SYNCHRONIZATION Related Applications [0001] This application claims the benefit of international application serial number PCT/CN2021/084776, filed March 31, 2021, the disclosure of which is hereby incorporated herein by reference in its entirety. Technical Field [0002] The present disclosure generally relates to the field of time synchronization, and more particularly to methods and devices for time synchronization in physical random access channel (PRACH) transmission. Background [0003] This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art. Time Sensitive Network for IIoT in NR [0004] For supporting Time Sensitive Network (TSN) time synchronization, the Fifth Generation System (5GS) is integrated with an external network as a TSN bridge (or a time-aware system). There are two synchronization systems considered, namely, the 5GS synchronization and the TSN domain synchronization. 5GS synchronization is specified in Third Generation Partnership Project (3GPP) specifications for the Next Generation (NG) Radio Access Network (RAN) synchronization, while TSN domain synchronization follows the Institute for Electrical and Electronics Engineers (IEEE) 802.1AS specification and provides synchronization services to the TSN network. [0005] 5GS time synchronization needs to satisfy stringent accuracy requirement in order to support inter-working with TSN. A demanding use case in the context of TSN- 5GS interworking is when TSN Grandmaster clocks are located at end stations connected to the User Equipment (UE) / Device-Side TSN Translators (DS-TTs). This new Release 17 use case involves two Uu interfaces in the 5GS path (i.e., the 5GS ingress to the 5GS egress) over which a TSN Grandmaster clock is relayed. One variant of the use case is illustrated in Figure 1, which shows TSN end-to-end timing delivery where the ingress is at UE1, wherein two UEs may be connected to different next generation NodeBs (gNBs), thereby introducing the potential for increased uncertainty compared to the case where each UE is connected to the same gNB. [0006] The 5GS synchronicity budget is the portion of the end-to-end synchronicity budget applicable between the ingress and egress of the 5G system, as shown in Figure 1. The per Uu interface synchronization error represents a portion of the end-to-end synchronicity budget and consists of the uncertainty introduced when (a) sending the Fifth Generation (5G) reference time from the gNB antenna to the UE antenna by including ReferenceTimeInfo in either a DLInformationTransfer Radio Resource Control (RRC) message or System Information Block (SIB) 9 (SIB9) and then (b) adjusting the 5G reference time to reflect the downlink propagation delay. [0007] The range of uncertainty for a single Uu interface shown in Table 1 below was agreed at 3GPP TSG-RAN WG2 #113-e. Table 1 – Range of Uncertainty for a Single Uu interface [0008] The Release17 RAN work item “Enhanced Industrial Internet of Things (IoT) and ultra-reliable and low latency communication (URLLC) support for NR (new radio)” has the following objective, where propagation delay compensation is used to achieve time synchronization between the UE and its associated gNB: Enhancements for support of time synchronization: a. RAN impacts of SA2 work on uplink time synchronization for TSN, if any. [RAN2] b. Propagation delay compensation enhancements (including mobility issues, if any). [RAN2, RAN1, RAN3, RAN4]. As agreed by RAN1 in RAN1#102e, the following options for propagation delay compensation are further studied in RAN1: ● Option 1: TA-based propagation delay o Option 1a: Propagation delay estimation based on legacy timing advance (TA) (potentially with enhanced TA indication granularity), o Option 1b: Propagation delay estimation based on timing advanced enhanced for time synchronization (similar to 1a but with updated RAN4 requirements to TA adjustment error and Te), o Option 1c: Propagation delay estimation based on a new dedicated signaling with finer delay compensation granularity (separated signaling from TA so that TA procedure is not affected); ● Option 2: RTT based delay compensation: o Propagation delay estimation based on an RAN managed Rx- Tx procedure intended for time synchronization (to expand or separate procedure/signaling to positioning). TA based Propagation Delay Compensation [0009] Timing Advance (TA) command is utilized in cellular communication for uplink transmission synchronization. It is further classified as two types: 1. In the beginning, at connection setup, an absolute timing advance command is communicated to a UE in the Medium Access Control (MAC) Protocol Data Unit (PDU) Random Access Response (RAR) or in the Absolute Timing Advance Command MAC Control Element (CE) of the Message B (MSGB). 2. After connection setup, a relative timing correction can be sent to a UE using Timing Advance Command MAC CE (e.g., UEs can move or due to multi-path because of changing environment). [0010] The downlink Propagation Delay (PD) can be estimated for a given UE by (a) first summing the TA value indicated by the Radio Access Response (RAR) and all subsequent TA values sent using the MAC CE and (b) taking some portion of the total TA value resulting from summation of all the TA values (e.g., 50% could be used assuming the downlink and uplink propagation delays are essentially the same). The PD can be utilized to understand time synchronization dynamics, e.g., accurately tracking the value of a clock at UE side relative to the value of that clock in other network nodes. RTT based Propagation Delay Compensation [0011] For the Round-Trip Time (RTT) based method, the UE Receive-to-Transmit (Rx-Tx) Time Difference and/or gNB Rx-Tx Time Difference are measured at UE side and gNB side, respectively, and then used to derive the propagation delay. [0012] For instance, two types of Timing Advance (T _ADV ) can be defined: - Type1: T _ADV = (gNB Rx – Tx time difference) + (UE Rx – Tx time difference); - Type2: T _ADV = gNB Rx – Tx time difference; With either Type 1 or Type 2, the propagation delay can be estimated as ½* T _ADV . [0013] For Type 2 T _ADV , the Rx – Tx time difference corresponds to a received uplink radio frame containing PRACH from the respective UE. PRACH Design in NR [0014] In New Radio (NR) up to 64 Zadoff-Chu (ZC) sequences are used for Physical Random Access Channel (PRACH) transmission during random access, and the set of random-access preambles x _u , _v (n) is generated according to: from which the frequency-domain representation is generated according to where L _RA = 839, L _RA = 139, L _RA = 1151, or L _RA = 571 depending on the PRACH preamble format as given by Tables 6.3.3.1-1 and 6.3.3.1-2 in 3GPP TS 38.211 V16.4.0, which are represented as Tables 2 and 3 below. Table 2: PRACH preamble formats for

Table 3: Preamble formats for L _RA א {139, 571, 1151} and Δf ^RA = 15 · 2 ^μ kHz where μ ∈ {0,1,2,3}. [0015] The bandwidth of a PRACH occasion is provided in Table 6.3.3.2-1 from 38.211, which is represented as Table 4 below. Table 4: Supported combinations of UL Time Synchronization in NR [0016] In RRC_CONNECTED, the gNB is responsible for maintaining the timing advance to keep the L1 synchronized. Serving cells having an uplink (UL) to which the same timing advance applies and using the same timing reference are grouped in a Timing Advance Group (TAG). Each TAG contains at least one serving cell with a configured uplink, and the mapping of each serving cell to a TAG is configured by RRC. [0017] For the primary TAG, the UE uses the Primary Cell (PCell) as timing reference, except with shared spectrum channel access where a Secondary Cell (SCell) can also be used in certain cases (see clause 7.1 of 3GPP TS 38.133). In a secondary TAG, the UE may use any of the activated SCells of this TAG as a timing reference cell but should not change it unless necessary. [0018] Timing advance updates are signaled by the gNB to the UE via MAC CE commands. Such commands restart a TAG-specific timer which indicates whether the L1 can be synchronized or not: when the timer is running, the L1 is considered synchronized, otherwise, the L1 is considered non-synchronized (in which case uplink transmission can only take place on PRACH). [0019] The TA timer is configured in TAG-Config Information Element (IE) in the IE MAC-CellGroupConfig which is used to configure MAC parameters for a cell group, including Discontinuous Reception (DRX). The TAG-Config IE is defined as: -- ASN1START -- TAG-TAG-CONFIG-START TAG-Config ::= SEQUENCE { tag-ToReleaseList SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG-Id OPTIONAL, -- Need N tag-ToAddModList SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG OPTIONAL -- Need N } TAG ::= SEQUENCE { tag-Id TAG-Id, timeAlignmentTimer TimeAlignmentTimer, ... } TimeAlignmentTimer ::= ENUMERATED {ms500, ms750, ms1280, ms1920, ms2560, ms5120, ms10240, infinity} -- TAG-TAG-CONFIG-STOP -- ASN1STOP Requirement of PRACH based Timing Estimation Error [0020] PRACH timing detection error tolerance (see 3GPP TS 38.104 V17.1.0) in NR is described as shown in the following excerpt from 3GPP TS 38.104. ***** START EXCERPT FROM 3GPP TS 38.104 ***** 8.4.2 PRACH detection requirements 8.4.2.1 General The probability of detection is the conditional probability of correct detection of the preamble when the signal is present. There are several error cases – detecting different preamble than the one that was sent, not detecting a preamble at all or correct preamble detection but with the wrong timing estimation. For AWGN and TDLC300-100, a timing estimation error occurs if the estimation error of the timing of the strongest path is larger than the time error tolerance given in Table 8.4.2.1-1. The performance requirements for high speed train (table 8.4.23-1 to 8.4.2.3-4) are optional. Table 8.4.2.1-1: Time error tolerance for AWGN and TDLC300-100 … 11.4.2.2 PRACH detection requirements 11.4.2.2.1 General The probability of detection is the conditional probability of correct detection of the preamble when the signal is present. There are several error cases – detecting different preamble than the one that was sent, not detecting a preamble at all or correct preamble detection but with the wrong timing estimation. For AWGN and TDLA30-300, a timing estimation error occurs if the estimation error of the timing of the strongest path is larger than the time error tolerance given in Table 11.4.2.2-1. Table 11.4.2.2-1: Time error tolerance for AWGN and TDLA30-300 Summary [0021] Systems and methods are disclosed for Physical Random Access Channel (RACH) transmission for enhanced time synchronization. In one embodiment, a method implemented by a User Equipment (UE) in a wireless communication system comprises transmitting a Physical Random Access Channel (PRACH) such that either: the PRACH has a first bandwidth that is greater than a second bandwidth defined for the PRACH in 3GPP New Radio (NR) Release 15 and 16, for a given PRACH sequence length and Physical Uplink Shared Channel (PUSCH) subcarrier spacing; or the PRACH uses a PRACH sequence length that is greater than a PRACH sequence length defined in 3GPP NR Release 15 and 16 for a given PRACH subcarrier spacing, for a given PUSCH subcarrier spacing, or both for a given PRACH subcarrier spacing and a given PUSCH subcarrier spacing; or the PRACH uses two or more frequency-division multiplexed PRACH sequences. In this manner, the PRACH transmission enables enhanced time synchronization. [0022] In one embodiment, the PRACH is transmitted such that the PRACH has a first bandwidth that is greater than a second bandwidth defined for the PRACH in 3GPP NR Release 15 and 16, for a given PRACH sequence length and PUSCH subcarrier spacing. In one embodiment, the PRACH uses a PRACH sequence of length 839 and a subcarrier spacing of 15 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz, 30 kilohertz, or 60 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 72 RBs, 36 RBs, or 18 RBs, respectively. In another embodiment, the PRACH uses a PRACH sequence of length 139 and a subcarrier spacing of 60 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz or 30 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 48 RBs or 24 RBs, respectively. In another embodiment, the PRACH uses a PRACH sequence of length 139 and a subcarrier spacing of 120 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz or 30 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 96 RBs or 48 RBs, respectively. [0023] In one embodiment, the PRACH is transmitted such that the PRACH uses a PRACH sequence length that is greater than a PRACH sequence length defined in 3GPP NR Release 15 and 16 for a given PRACH subcarrier spacing, for a given PUSCH subcarrier spacing, or both for a given PRACH subcarrier spacing and a given PUSCH subcarrier spacing. In one embodiment, the PRACH uses a PRACH sequence of length 1291 and a subcarrier spacing of 5 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz, 30 kilohertz, or 60 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 36 RBs, 18 RBs, or 9 RBs, respectively. In another embodiment, the PRACH uses a PRACH sequence of length 571 and a subcarrier spacing of 30 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz or 30 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 96 RBs or 48 RBs, respectively. In another embodiment, the PRACH uses a PRACH sequence of length 1151 and a subcarrier spacing of 15 kilohertz and an associated PUSCH subcarrier spacing is either 15 kilohertz or 30 kilohertz such that a number of Resource Blocks, RBs, allocated for the PRACH expressed in number of RBs for PUSCH is either 96 RBs or 48 RBs, respectively. In one embodiment, the PRACH is transmitted in a licensed band and reuses a PRACH sequence defined for an unlicensed band. In one embodiment, a time-continuous signal on antenna port p for PRACH is defined by: In another embodiment, a time-continuous signal on antenna port p for PRACH is defined by: [0024] In one embodiment, two or more different choices for the PRACH sequence length used for the PRACH for a same combination the given PRACH subcarrier spacing and the given PUSCH subcarrier spacing, and the method further comprises receiving (201), from a network node, a parameter that indicates one of the two or more different choses for the PRACH sequence length to be used for transmission of the PRACH by the UE. In one embodiment, the parameter further configures which logical index to use to determine a PRACH sequence number for the PRACH. In one embodiment, the PRACH sequence number, u, is determined from the logical index, i, by: where N _ZC is a number of elements in respective Zadoff-Chu sequence. [0025] In one embodiment, the PRACH is transmitted such that the PRACH uses two or more frequency-division multiplexed PRACH sequences. [0026] Corresponding embodiments of a UE are also disclosed. In one embodiment, a UE for a wireless communication system is adapted to transmit a PRACH such that: the PRACH has a first bandwidth that is greater than a second bandwidth defined for the PRACH in 3GPP NR Release 15 and 16, for a given PRACH sequence length and PUSCH subcarrier spacing; the PRACH uses a PRACH sequence length that is greater than a PRACH sequence length defined in 3GPP NR Release 15 and 16 for a given PRACH subcarrier spacing, for a given PUSCH subcarrier spacing, or both for a given PRACH subcarrier spacing and a given PUSCH subcarrier spacing; or the PRACH uses two or more frequency-division multiplexed PRACH sequences. [0027] In another embodiment, a UE for a wireless communication system comprises a network interface, a processor associated with the network interface, and memory comprising instructions executable by the processor whereby the UE is configured to transmit a PRACH such that: the PRACH has a first bandwidth that is greater than a second bandwidth defined for the PRACH in 3GPP NR Release 15 and 16, for a given PRACH sequence length and PUSCH subcarrier spacing; the PRACH uses a PRACH sequence length that is greater than a PRACH sequence length defined in 3GPP NR Release 15 and 16 for a given PRACH subcarrier spacing, for a given PUSCH subcarrier spacing, or both for a given PRACH subcarrier spacing and a given PUSCH subcarrier spacing; or the PRACH uses two or more frequency-division multiplexed PRACH sequences. [0028] In another embodiment, a method implemented by a UE in a wireless communication system comprises transmitting one or more uplink signals, other than a PRACH transmission, such that the one or more uplink signals occupy a required minimum bandwidth for enhanced timing advance accuracy for a Time-Sensitive Network (TSN) application. [0029] In one embodiment, the required minimum bandwidth is defined as a number of Physical Resource Blocks (PRBs). [0030] In one embodiment, the required minimum bandwidth is associated with a subcarrier spacing used for transmitting the one or more uplink signals. [0031] In one embodiment, the one or more uplink signals comprises a Demodulation Reference Signal (DMRS) of a PUSCH. [0032] In one embodiment, the one or more uplink signals comprise a Sounding Reference Signal (SRS). [0033] In one embodiment, the required minimum bandwidth is inversely related to a minimum receiving time detection error for the TSN application and inversely related to a subcarrier spacing used for the one or more uplink signals. In one embodiment, the required minimum bandwidth further comprises a defined or configured margin. [0034] Corresponding embodiments of a UE are also disclosed. In one embodiment, a UE for a wireless communication system is adapted to transmit one or more uplink signals, other than a PRACH transmission, such that the one or more uplink signals occupy a required minimum bandwidth for enhanced timing advance accuracy for a TSN application. [0035] In another embodiment, a UE for a wireless communication system comprises a network interface, a processor associated with the network interface, and memory comprising instructions executable by the processor whereby the UE is configured to transmit one or more uplink signals, other than a PRACH transmission, such that the one or more uplink signals occupy a required minimum bandwidth for enhanced timing advance accuracy for a TSN application. [0036] Embodiments of a method performed by a network node are also disclosed. In one embodiment, a method implemented by a network node in a wireless communication system comprises receiving a PRACH wherein: the PRACH has a first bandwidth that is greater than a second bandwidth defined for the PRACH in 3GPP NR Release 15 and 16, for a given PRACH sequence length and PUSCH subcarrier spacing; or the PRACH uses a PRACH sequence length that is greater than a PRACH sequence length defined in 3GPP NR Release 15 and 16 for a given PRACH subcarrier spacing, for a given PUSCH subcarrier spacing, or both for a given PRACH subcarrier spacing and a given PUSCH subcarrier spacing; or the PRACH uses two or more frequency-division multiplexed PRACH sequences. [0037] In another embodiment, a method implemented by a network node in a wireless communication system comprises receiving one or more uplink signals, other than a PRACH transmission, wherein the one or more uplink signals occupy a required minimum bandwidth for enhanced timing advance accuracy for a TSN application. [0038] In another embodiment, a method implemented by a network node in a wireless communication system comprises configuring a wireless communication device with a PUSCH allocation for a PUSCH transmission for a TSN, where the PUSCH allocation is in accordance with a PUSCH allocation type that uses interlaced resource blocks, and receiving, from the wireless communication device, a PUSCH transmission in accordance with the configured PUSCH allocation. Brief Description of the Drawings [0039] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. [0040] Figure 1 is a diagram illustrating TSN end-to-end timing delivery; [0041] Figure 2 is a flow chart illustrating a method implemented on a first terminal device according to some embodiments of the present disclosure; [0042] Figure 3 is a flow chart illustrating a method implemented on a second terminal device according to some embodiments of the present disclosure; [0043] Figure 4 is a flow chart illustrating a method implemented on a network node according to some embodiments of the present disclosure; [0044] Figure 5 is a block diagram illustrating a first terminal device according to some embodiments of the present disclosure; [0045] Figure 6 is another block diagram illustrating a first terminal device according to some embodiments of the present disclosure; [0046] Figure 7 is a block diagram illustrating a second terminal device according to some embodiments of the present disclosure; [0047] Figure 8 is another block diagram illustrating a second terminal device according to some embodiments of the present disclosure; [0048] Figure 9 is a block diagram illustrating a network node according to some embodiments of the present disclosure; [0049] Figure 10 is another block diagram illustrating a network node according to some embodiments of the present disclosure; [0050] Figure 11 is a block diagram illustrating a wireless communication system according to some embodiments of the present disclosure; [0051] Figure 12 is a block diagram illustrating a wireless communication system according to some embodiments of the present disclosure; [0052] Figure 13 is a block diagram schematically illustrating a telecommunication network connected via an intermediate network to a host computer; [0053] Figure 14 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and [0054] Figs. 15 to 18 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station, and a user equipment. Detailed Description [0055] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. [0056] References in the specification to “one embodiment”, “an embodiment”, “an example embodiment” etc. indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. [0057] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure. [0058] In the following detailed description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, cooperate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other. [0059] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other forms of propagated signals – such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non- volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on, that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interfaces to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. One or more parts of an embodiment of the present disclosure may be implemented using different combinations of software, firmware, and/or hardware. [0060] There are problems in the existing solution for Fifth Generation System (5GS) and Time-Sensitive Network (TSN) interworking. In New Radio (NR) up to NR Release 16, the Timing Advance (TA) estimated based on the Physical Random Access Channel (PRACH) may have a detection time error larger than the requirement of maximum time error for the TSN, which makes the uplink timing at the next generation NodeB (gNB) side not as synchronized as required by the TSN. [0061] This issue mainly happens in low band when a small Subcarrier Spacing (SCS) is applied as the number of Physical Resource Blocks (PRBs) used by one PRACH preamble transmission is fixed, for example, always 12 PRBs if using short sequence as preamble format. Thus, the PRACH bandwidth is smaller when a smaller SCS is used. This leads to larger detection error since the detection error is approximately inverse of the uplink signal bandwidth. [0062] Reference signals other than PRACH may have similar issues when the occupied bandwidth is not wide enough for accurate TA estimation required by the TSN. [0063] Systems and methods are disclosed herein that provide a solution(s) to the aforementioned and/or other problems. The present disclosure provides methods on how to improve the time estimation accuracy to ensure the uplink synchronization in a TSN, including ● PRACH based methods, e.g., long PRACH sequence in frequency domain, and/or larger SCS of PRACH, ● SRS (sounding reference signal) and other reference signals or channel based methods. [0064] According to a first aspect of the present disclosure, a method implemented by a first terminal device is provided. The method comprises: receiving a changed parameter value from a network node; and transmitting a PRACH with a bandwidth increased based on the changed parameter value to a network node. [0065] In an embodiment of the first aspect, the changed parameter value may be configured by radio resource control (RRC) signaling received from the network node. [0066] In a further embodiment of the first aspect, the parameter value may a value of a PRACH SCS. [0067] In another further embodiment of the first aspect, the parameter value may be a value of a length of a sequence. [0068] According to a second aspect of the present disclosure, a method implemented by a second terminal device is provided. The method comprises: receiving a minimum number of PRBs or a Physical Uplink Shared Channel (PUSCH) allocation type which uses interlaced resource blocks from a network node; and performing uplink transmissions using the received minimum number of PRBs or the received PUSCH allocation type which uses the interlaced resource blocks. [0069] According to a third aspect of the present disclosure, a method implemented by a network node is provided. The method comprises: configuring at least one of a changed parameter value, a minimum number of PRBs, and a PUSCH allocation type which uses interlaced resource blocks; transmitting the changed parameter value to a first terminal device or transmitting the minimum number of PRBs or the PUSCH allocation type to a second terminal device; and receiving a PRACH with an increased bandwidth from the first terminal device or receiving uplink transmissions from the second terminal device. [0070] According to a fourth aspect of the present disclosure, a first terminal device is provided. The first terminal device comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the first terminal device to perform operations of the method according to the above first aspect. [0071] According to a fifth aspect of the present disclosure, a first terminal device is provided. The first terminal device is adapted to perform the method of the above first aspect. [0072] According to a sixth aspect of the present disclosure, a second terminal device is provided. The second terminal device comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the second terminal device to perform operations of the method according to the above second aspect. [0073] According to a seventh aspect of the present disclosure, a second terminal device is provided. The second terminal device is adapted to perform the method of the above second aspect. [0074] According to an eighth aspect of the present disclosure, a network node is provided. The network node comprises a processor and a memory communicatively coupled to the processor. The memory is adapted to store instructions which, when executed by the processor, cause the network node to perform operations of the method according to the above third aspect. [0075] According to a ninth aspect of the present disclosure, a network node is provided. The network node is adapted to perform the method of the above third aspect. [0076] According to a tenth aspect of the present disclosure, a wireless communication system is provided. The wireless communication system comprises: a first terminal device of the above fourth or fifth aspect; and a network node of the above eighth or ninth aspect, communicating with at least the first terminal device. [0077] According to an eleventh aspect of the present disclosure, a wireless communication system is provided. The wireless communication system comprises: a second terminal device of the above sixth or seventh aspect; and a network node of the above eighth or ninth aspect, communicating with at least the second terminal device. [0078] According to a twelfth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a first terminal device, the computer program causes the first terminal device to perform operations of the method according to the above first aspect. [0079] According to a thirteenth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a second terminal device, the computer program causes the second terminal device to perform operations of the method according to the above second aspect. [0080] According to a fourteenth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon is provided. When the computer program is executed by a set of one or more processors of a network node, the computer program causes the network node to perform operations of the method according to the above third aspect. [0081] In this way, the present disclosure provides systems and methods on how to reduce the time estimation error based on detection of uplink signal to ensure clock synchronization in a 5G system, which is required to satisfy the performance of a time sensitive network. PRACH with Larger SCS [0082] In this section, the description focuses on transmitting PRACH with a larger SCS so that the receiver timing estimation error on the network side is reduced. [0083] Embodiment 1: A larger SCS for PRACH as compared to NR Release 15/16 can be used for a PRACH transmission. [0084] In NR, 1.25 kilohertz (kHz), 5kHz, 15kHz, or 30kHz can be used for PRACH transmission for different PRACH formats in Frequency Range 1 (FR1), whereas 60kHz or 120kHz SCS is used for Frequency Range 2 (FR2). For each combination (i.e., each row), Table 7 below also shows the bandwidth of a PRACH and the theoretical timing estimation error from PRACH detection. The theoretical timing estimation error is 1/(bandwidth of PRACH). Table 7. PRACH band and theoretical timing estimation error from PRACH detection in NR Rel-16 [0085] To reduce the time estimation error, PRACH with larger bandwidth can be introduced for Physical Uplink Shared Channel (PUSCH) with SCS Δf א 15,30,60 kHz. This can be achieved by using larger PRACH SCS Δf ^RA , for a given PUSCH SCS and a given length of PRACH sequence length. As an example, new entries are introduced in Table 8 below, shown in the rows with bold, underlined numbers, where larger PRACH SCS is introduced when PUSCH SCS is 15kHz or 30kHz or 60kHz. Specifically, for the entries with PUSCH SCS Δf א 15,30 and PRACH sequence length L = 139, by using a PRACH SCS Δf = 60 kHz instead of Δf =30 kHz, the PRACH bandwidth is doubled to 8.64 MHz. Table 8. New entries for PRACH band and theoretical timing estimation error from PRACH detection PRACH Extension in Frequency Domain based on the Time Error Requirement [0086] In this section, the description focuses on transmitting PRACH with a longer sequence so that the bandwidth of a PRACH occasion is increased, and the receiver timing estimation error on the network side is reduced. [0087] Embodiment 2: A different PRACH sequence with proper band compared to NR Release 15/16 for one specific subcarrier spacing of PRACH and/or one specific subcarrier spacing of PUSCH can be used for a PRACH transmission in TSN. For instance, as shown in Table 9 below, three length-1291 PRACH sequences are introduced for PRACH with 5kHz SCS, where length-1291 PRACH sequence is new, and ^{longer, compared to the corresponding NR Release 15/16 sequence length of 839 for} Δf RA =5 kHz. [0088] Embodiment 3: The longer sequence with length 571 and length 1151 can be used for licensed band. For instance, as shown in Table 9, the length-571/1151 PRACH sequences of unlicensed band are reused for licensed band when PUSCH SCS is 15kHz or 30kHz. [0089] In summary, to reduce the time estimation error, longer PRACH sequences are introduced, i.e., larger L _RA values for a given Δf ^RA , as shown in the rows with bold, underlined numbers in Table 9. For a given value of Δf ^RA , longer lengths of PRACH sequences lead to a large bandwidth of a PRACH occasion, thus providing better PRACH timing detection accuracy.

Table 9. New entries for PRACH band and theoretical timing estimation error from PRACH detection [0090] Embodiment 3a: Whether to use a long sequence or a short sequence is configured by RRC signaling. [0091] If two or more different choices of PRACH sequence length exist for the same combination of { Δf, Δf ^RA } as shown in Table 9, then a parameter is needed to choose the PRACH sequence length for a PRACH occasion. [0092] As an example, a prach-RootSequenceIndex-r17 parameter (see example below) can be used to choose which length of PRACH sequence is to be used for a PRACH occasion. If the optional parameter prach-RootSequenceIndex-r17 is configured, then it provides the PRACH sequence length, i.e., PRACH sequence length takes the larger values and can be length 571 or 1151 or 1291. Otherwise (i.e., optional parameter prach-RootSequenceIndex-r17 is absent), then the PRACH sequence length is indicated by the existing parameter prach-RootSequenceIndex, i.e., PRACH sequence length takes the shorter values and can be length 139 or 839. [0093] Meanwhile this parameter will also configure which logical index to use to determine the PRACH sequence number as described in Embodiment 4 below. prach-RootSequenceIndex CHOICE { l839 INTEGER (0..837) l139 INTEGER (0..1137) } … prach-RootSequenceIndex-r17 CHOICE { l571 INTEGER (0..569) l1151 INTEGER (0..1149) l1291 INTEGER (0..1289) } OPTIONAL -- Need R [0094] Embodiment 4: A new table is introduced to define the logical index i to sequence number u mapping for preamble formats with new PRACH sequence length. [0095] In a sub-embodiment of this embodiment 4, which root sequence index is used can be determined by a logical index configured by RRC signaling. [0096] As an example, a new table can be introduced to define the mapping from logical index i to root index u for preamble formats with new PRACH sequence length. The logical index selected can be signaled as shown in the example for embodiment 3. For example, if prach-RootSequenceIndex-r17 chooses length 571 in the first part of the signaling, then the second part of the signaling (i.e., INTEGER (0..569)) provides an integer which is used as the logical index i. Logical index i is then mapped to root index u for generating PRACH sequences of length 571. [0097] Regarding the mapping table generation, in order to allow the efficient implementation of the pair of correlators matched to the complementary root Zadoff- Chu sequences defined by root indices u and N _ZC - u, similar to the mapping for length 139 PRACH sequence in NR Rel-15, the mapping can be done in pairs of 1, N _ZC - 1,2, N _ZC - 2, 3, N _ZC - 3, …. Equivalently, the sequence root index u could be determined ^{from a logical index i by} [0098] Embodiment 5: When the long sequence (i.e., Zadoff-Chu sequences of lengths 571 and 1151) used for unlicensed band is reused for licensed band, the Orthogonal Frequency Division Multiplexing (OFDM) symbol generation formulation does not need to be associated with a Resource Block (RB) set definition. [0099] In one example, if the length {571, 1151} PRACH sequence is used for TSN in licensed operation, the formula for PRACH signal generation can be updated in the following way. The time-continuous signal on antenna port p for PRACH is defined by: Alternatively, the change to the specifications can be in the following way. The time- [0100] Embodiment 6: Multiple PRACH sequences Frequency Division Multiplexed (FDM-ed) can be used in an aggregate to form a wider bandwidth signal, thus allowing more accurate PRACH arrival time detection. When the UE transmits the multiple FDM- ed PRACH sequences, the gNB can generate more accurate timing advance value for the UE. TA Maintenance with Respect to Frequency Domain Resource Allocation for Channels Other than PRACH [0101] After each random access, the TA is estimated based on uplink transmissions other than PRACH, e.g. based on the Demodulation Reference Signal (DMRS) of PUSCH or the Sounding Reference Signal (SRS). To improve the TA estimation accuracy, different resource allocation types or a different PRB allocation with a minimum number of required PRBs can be considered for a TSN application. [0102] Embodiment 7: A minimum number of PRBs is used so that the uplink signals can occupy a required minimum bandwidth. [0103] In a sub-embodiment of this embodiment 7, the required minimum number of PRBs is associated with the subcarrier spacing. [0104] As an example, when 15kHz SCS is used, a minimum number of 28 PRBs can be required so that a 200 nanosecond (ns) receiving time detection error can be ^{ensured. This is calculated according to following formula:} [0105] If a margin is needed, a minimum number of PRBs required can be 28+N_margin, e.g. minimum 30 PRBs can be required for 15kHz SCS if taking two extra PRBs (i.e., N_margin = 2) as a margin, for example, to account for a fading channel condition. [0106] Similarly, if the receiving time detection error of the uplink signal is desired to be 100ns instead, then a minimum of 56 PRBs are needed assuming 15 kHz SCS for the uplink signal. [0107] Embodiment 8: To maintain a more accurate TA after random access, uplink resource allocation type 2 can be used for PUSCH in TSN. PUSCH allocation type 2 uses the interlaced resource blocks to spread the PUSCH transmission over a wider bandwidth. An interlace starts on the first PRB within a specified band, with an initial offset of 0 to M-1 depending on an interlace index, and includes every M ^th PRB within the band. [0108] With uplink resource allocation type 2, the DMRS and PUSCH data can occupy a wider band compared to other resource allocation types so that a more accurate TA can be maintained. [0109] Figure 2 is a flow chart illustrating a method 200 implemented on a first terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a UE associated with the above Embodiments 1-6, but they are not limited thereto. The operations in this and other flow charts will be described with reference to the exemplary embodiments of the other figures. However, it should be appreciated that the operations of the flow charts may be performed by embodiments of the present disclosure other than those discussed with reference to the other figures, and the embodiments of the present disclosure discussed with reference to these other figures may perform operations different than those discussed with reference to the flow charts. [0110] In one embodiment, the UE may receive a changed parameter value from a network node (block 201). The UE may transmit a PRACH with a bandwidth increased based on the increased parameter value to a network node (block 202). [0111] As an example, the changed parameter value may be configured by RRC signaling received from the network node. [0112] As an example, the parameter value may be a value of a PRACH SCS. [0113] As an example, the parameter value may be a value of a length of a sequence. [0114] As a further example, the sequence with the increased length may be used or reused for a licensed band. [0115] As a further example, a first parameter for selecting a PRACH sequence length for a PRACH occasion may be received along with the changed parameter value from the network node. [0116] As a further example, if the first parameter for selecting the PRACH sequence is not received, the PRACH sequence length may be indicated by a second parameter. [0117] As a further example, the first parameter may configure which logical index to use to determine a PRACH sequence number. [0118] As an example, the method 200 may further comprise receiving RRC signaling which configures logical indices indicating which root indices are used from the network node. [0119] As a further example, the method 200 may further comprise configuring a table to define a mapping of the logical indices to root indices for preamble formats with a new PRACH sequence length. [0120] As a further example, the mapping may be performed in alternate pairs of the root indices and their complementary root Zadoff-Chu sequences. [0121] As a further example, in the case that the Zadoff-Chu sequences used for an unlicensed band are reused for a licensed band, PRACH signal generation may not be associated with a resource block set definition and may be updated. [0122] As an example, a plurality of frequency division multiplexed PRACH sequences may be transmitted in an aggregate. [0123] As an example, the network node may be a gNB, a base station or an access point. [0124] Furthermore, the present disclosure provides a first terminal device which is adapted to perform the method 200. [0125] Figure 3 is a flow chart illustrating a method 300 implemented on a second terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a UE associated with the above Embodiments 7-8, but they are not limited thereto. [0126] In one embodiment, the UE may receive a minimum number of PRB or a PUSCH allocation type which uses interlaced resource blocks from a network node (block 301). The UE may perform uplink transmissions using the received minimum number of PRBs or the received PUSCH allocation type which uses the interlaced resource blocks (block 302). [0127] As an example, the uplink transmissions may be performed without a PRACH. [0128] As an example, the uplink transmissions may include DMRSs of a PUSCH or SRSs. [0129] As an example, the number of the PRBs may be in proportion to a receiving time detection error of the uplink transmissions and in inverse proportion to a frequency for an SCS and the number of subcarriers per PRB. [0130] As a further example, a margin may be configured for the minimum number of PRBs. [0131] As an example, the interlace of the PRBs may begin with a first PRB within a predetermined band, and may be associated with every M-th PRB within the band, with an initial offset of 0 to M-1 depending on an interlace index, wherein M is an integer greater than 1. [0132] As an example, the network node may be a gNB, a base station or an access point. [0133] Furthermore, the present disclosure provides a second terminal device which is adapted to perform the method 300. [0134] Figure 4 is a flow chart illustrating a method 400 implemented on a network node according to some embodiments of the present disclosure. [0135] In one embodiment, the network node may configure at least one of a changed parameter value, a minimum number of PRBs, and a PUSCH allocation type which uses interlaced resource blocks (block 401). [0136] The network node may transmit the changed parameter value to a first UE (block 402) and receive a PRACH with an increased bandwidth from the first UE (block 404). [0137] The network node may also transmit the minimum number of PRBs or the PUSCH allocation type to a second UE (block 403) and receive uplink transmissions from the second UE (block 405). [0138] As an example, the changed parameter value may be configured by RRC signaling transmitted by the network node. [0139] As an example, the parameter value may be a value of a PRACH SCS. [0140] As an example, the parameter value may be a value of a length of a sequence. [0141] As a further example, the sequence with the increased length may be used or reused for a licensed band. [0142] As a further example, a first parameter for selecting a PRACH sequence length for a PRACH occasion may be transmitted to the first UE along with the changed parameter value. [0143] As a further example, if the first parameter for selecting the PRACH sequence is not transmitted, the PRACH sequence lengths may be indicated by a second parameter. [0144] As a further example, the first parameter may configure which logical index to use to determine a PRACH sequence number. [0145] As an example, the method 400 may further comprise transmitting RRC signaling which configures logical indices indicating which root indices are used to the first UE. [0146] As an example, a plurality of frequency division multiplex PRACH sequences may be received in an aggregate from the first UE. [0147] As an example, the uplink transmissions may be received without a PRACH. [0148] As a further example, the method 400 may further comprise, after each random access, estimating a timing advance based on the uplink transmissions. [0149] As a further example, the uplink transmissions may include DMRSs of a PUSCH or SRSs. [0150] As an example, the number of the PRBs may be in proportion to a receiving time detection error of the uplink transmissions and in inverse proportion to a frequency for an SCS and the number of subcarriers per PRB. [0151] As a further example, a margin may be configured for the minimum number of PRBs. [0152] As an example, the interlace of the PRBs may begin with a first PRB within a predetermined band, and may be associated with every M-th PRB within the band, with an initial offset of 0 to M-1 depending on an interlace index, wherein M is an integer greater than 1. [0153] As an example, the network node may be a gNB, a base station or an access point. [0154] Furthermore, the present disclosure provides a network node which is adapted to perform the method 400. [0155] Figure 5 is a block diagram illustrating a first terminal device 500 according to some embodiments of the present disclosure. As an example, the first terminal device 500 may act as the UE associated with the above Embodiments 1-6, but it is not limited thereto. It should be appreciated that the first terminal device 500 may be implemented using components other than those illustrated in Figure 5. [0156] With reference to Figure 5, the first terminal device 500 may comprise at least a processor 501, a memory 502, a network interface 503 and a communication medium 504. The processor 501, the memory 502 and the network interface 503 may be communicatively coupled to each other via the communication medium 504. [0157] The processor 501 may include one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory 502, and selectively execute the instructions. In various embodiments, the processor 501 may be implemented in various ways. As an example, the processor 501 may be implemented as one or more processing cores. As another example, the processor 501 may comprise one or more separate microprocessors. In yet another example, the processor 501 may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In still another example, the processor 501 may provide specific functionality by using an ASIC and/or by executing computer- executable instructions. [0158] The memory 502 may include one or more computer-usable or computer- readable storage medium capable of storing data and/or computer-executable instructions. It should be appreciated that the storage medium is preferably a non- transitory storage medium. [0159] The network interface 503 may be a device or article of manufacture that enables the terminal device 500 to send data to or receive data from other devices. In different embodiments, the network interface 503 may be implemented in different ways. As an example, the network interface 503 may be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a network interface (e.g., Wi-Fi, WiMax, etc.), or another type of network interface. [0160] The communication medium 504 may facilitate communication among the processor 501, the memory 502 and the network interface 503. The communication medium 504 may be implemented in various ways. For example, the communication medium 504 may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium. [0161] In the example of Figure 5, the instructions stored in the memory 502 may include those that, when executed by the processor 501, cause the first terminal device 500 to implement the method described with respect to Figure 2. [0162] Figure 6 is another block diagram illustrating a first terminal device 600 according to some embodiments of the present disclosure. As an example, the first terminal device 600 may act as the UE associated with the above Embodiments 1-6, but it is not limited thereto. It should be appreciated that the first terminal device 600 may be implemented using components other than those illustrated in Figure 6. [0163] With reference to Figure 6, the terminal device 600 may comprise at least a receiving unit 601 and a transmission unit 602. The receiving unit 601 may be adapted to perform at least the operation described in the block 201 of Figure 2. The transmission unit 602 may be adapted to perform at least the operation described in the block 202 of Figure 2. [0164] Figure 7 is a block diagram illustrating a second terminal device 700 according to some embodiments of the present disclosure. As an example, the second terminal device 700 may act as the UE associated with the above Embodiments 7-8, but it is not limited thereto. It should be appreciated that the second terminal device 700 may be implemented using components other than those illustrated in Figure 7. [0165] With reference to Figure 7, the network node 700 may comprise at least a processor 701, a memory 702, a network interface 703 and a communication medium 704. The processor 701, the memory 702 and the network interface 703 are communicatively coupled to each other via the communication medium 704. [0166] The processor 701, the memory 702, the network interface 703 and the communication medium 704 are structurally similar to the processor 501, the memory 502, the network interface 503 and the communication medium 504 respectively, and will not be described herein in detail. [0167] In the example of Figure 7, the instructions stored in the memory 702 may include those that, when executed by the processor 701, cause the second terminal device 700 to implement the method described with respect to Figure 3. [0168] Figure 8 is another block diagram illustrating a second terminal device 800 according to some embodiments of the present disclosure. As an example, the second terminal device 800 may provide act as the UE associated with the above Embodiments 7-8, but it is not limited thereto. It should be appreciated that the second terminal device 800 may be implemented using components other than those illustrated in Figure 8. [0169] With reference to Figure 8, the second terminal device 800 may comprise at least a receiving unit 801 and a transmission unit 802. The receiving unit 801 may be adapted to perform at least the operation described in the block 301 of Figure 3. The transmission unit 802 may be adapted to perform at least the operation described in the block 302 of Figure 3. [0170] Figure 9 is a block diagram illustrating a network node 900 according to some embodiments of the present disclosure. As an example, the network node 900 may act as the network node, but it is not limited thereto. It should be appreciated that the network node 900 may be implemented using components other than those illustrated in Figure 9. [0171] With reference to Figure 9, the network node 900 may comprise at least a processor 901, a memory 902, a network interface 903 and a communication medium 904. The processor 901, the memory 902 and the network interface 903 are communicatively coupled to each other via the communication medium 904. [0172] The processor 901, the memory 902, the network interface 903 and the communication medium 904 are structurally similar to the processor 501 or 701, the memory 502 or 702, the network interface 503 or 703 and the communication medium 504 or 704 respectively, and will not be described herein in detail. [0173] In the example of Figure 9, the instructions stored in the memory 902 may include those that, when executed by the processor 901, cause the network node 900 to implement the method described with respect to Figure 4. [0174] Figure 10 is another block diagram illustrating a network node 1000 according to some embodiments of the present disclosure. As an example, the network node 1000 may provide act as the network node, but it is not limited thereto. It should be appreciated that the network node 1000 may be implemented using components other than those illustrated in Figure 10. [0175] With reference to Figure 10, the network node 1000 may comprise at least a configuration unit 1001, a transmission unit 1002 and a receiving unit 1003. The configuration unit 1001 may be adapted to perform at least the operation described in the block 401 of Figure 4. The transmission unit 1002 may be adapted to perform at least the operations described in the blocks 402 and 403 of Figure 4. The receiving unit 1003 may be adapted to perform at least the operations described in the blocks 404 and 405 of Figure 4. [0176] The units shown in Figs. 6, 8 and 10 may constitute machine-executable instructions embodied within a machine, e.g., readable medium, which when executed by a machine will cause the machine to perform the operations described. Besides, any of these units may be implemented as hardware, such as an application specific integrated circuit (ASIC), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA) or the like. [0177] Moreover, it should be appreciated that the arrangements described herein are set forth only as examples. Other arrangements (e.g., more controllers or more detectors, etc.) may be used in addition to or instead of those shown, and some units may be omitted altogether. Functionality and cooperation of these units are correspondingly described in more detail with reference to Figs. 2-4. [0178] Figure 11 is a block diagram illustrating a wireless communication system 1100 according to some embodiments of the present disclosure. The wireless communication system 1100 comprises at least a first terminal device 1101 and a network node 1102. In one embodiment, the first terminal device 1101 may act as the terminal device 500 or 600 as depicted in Figure 5 or 6, and the network node 1102 may act as the network node 900 or 1000 as depicted in Figure 9 or 10. In one embodiment, the first terminal device 1101 and the network node 1102 may communicate with each other. [0179] Figure 12 is a block diagram illustrating a wireless communication system 1200 according to some embodiments of the present disclosure. The wireless communication system 1200 comprises at least a second terminal device 1201 and a network node 1202. In one embodiment, the second terminal device 1201 may act as the terminal device 700 or 800 as depicted in Figure 7 or 8, and the network node 1202 may act as the network node 900 or 1000 as depicted in Figure 9 or 10. In one embodiment, the second terminal device 1201 and the network node 1202 may communicate with each other. [0180] Figure 13 is a block diagram schematically illustrating a telecommunication network connected via an intermediate network to a host computer. [0181] With reference to Figure 13, in accordance with an embodiment, a communication system includes a telecommunication network 1310, such as a 3GPP- type cellular network, which comprises an access network 1311, such as a radio access network, and a core network 1314. The access network 1311 comprises a plurality of base stations 1312a, 1312b, 1312c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1313a, 1313b, 1313c. Each base station 1312a, 1312b, 1312c is connectable to the core network 1314 over a wired or wireless connection 1315. A first user equipment (UE) 1391 located in coverage area 1313c is configured to wirelessly connect to, or be paged by, the corresponding base station 1312c. A second UE 1392 in coverage area 1313a is wirelessly connectable to the corresponding base station 1312a. While a plurality of UEs 1391, 1392 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1312. [0182] The telecommunication network 1310 is itself connected to a host computer 1330, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 1330 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 1321, 1322 between the telecommunication network 1310 and the host computer 1330 may extend directly from the core network 1314 to the host computer 1330 or may go via an optional intermediate network 1320. The intermediate network 1320 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1320, if any, may be a backbone network or the Internet; in particular, the intermediate network 1320 may comprise two or more sub-networks (not shown). [0183] The communication system of Figure 13 as a whole enables connectivity between one of the connected UEs 1391, 1392 and the host computer 1330. The connectivity may be described as an over-the-top (OTT) connection 1350. The host computer 1330 and the connected UEs 1391, 1392 are configured to communicate data and/or signaling via the OTT connection 1350, using the access network 1311, the core network 1314, any intermediate network 1320 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1350 may be transparent in the sense that the participating communication devices through which the OTT connection 1350 passes are unaware of routing of uplink and downlink communications. For example, a base station 1312 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1330 to be forwarded (e.g., handed over) to a connected UE 1391. Similarly, the base station 1312 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1391 towards the host computer 1330. [0184] Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Figure 14. In a communication system 1400, a host computer 1410 comprises hardware 1415 including a communication interface 1416 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1400. The host computer 1410 further comprises processing circuitry 1418, which may have storage and/or processing capabilities. In particular, the processing circuitry 1418 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 1410 further comprises software 1411, which is stored in or accessible by the host computer 1410 and executable by the processing circuitry 1418. The software 1411 includes a host application 1412. The host application 1412 may be operable to provide a service to a remote user, such as a UE 1430 connecting via an OTT connection 1450 terminating at the UE 1430 and the host computer 1410. In providing the service to the remote user, the host application 1412 may provide user data which is transmitted using the OTT connection 1450. [0185] The communication system 1400 further includes a base station 1420 provided in a telecommunication system and comprising hardware 1425 enabling it to communicate with the host computer 1410 and with the UE 1430. The hardware 1425 may include a communication interface 1426 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1400, as well as a radio interface 1427 for setting up and maintaining at least a wireless connection 1470 with a UE 1430 located in a coverage area (not shown in Figure 14) served by the base station 1420. The communication interface 1426 may be configured to facilitate a connection 1460 to the host computer 1410. The connection 1460 may be direct or it may pass through a core network (not shown in Figure 14) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1425 of the base station 1420 further includes processing circuitry 1428, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 1420 further has software 1421 stored internally or accessible via an external connection. [0186] The communication system 1400 further includes the UE 1430 already referred to. Its hardware 1435 may include a radio interface 1437 configured to set up and maintain a wireless connection 1470 with a base station serving a coverage area in which the UE 1430 is currently located. The hardware 1435 of the UE 1430 further includes processing circuitry 1438, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 1430 further comprises software 1431, which is stored in or accessible by the UE 1430 and executable by the processing circuitry 1438. The software 1431 includes a client application 1432. The client application 1432 may be operable to provide a service to a human or non-human user via the UE 1430, with the support of the host computer 1410. In the host computer 1410, an executing host application 1412 may communicate with the executing client application 1432 via the OTT connection 1450 terminating at the UE 1430 and the host computer 1410. In providing the service to the user, the client application 1432 may receive request data from the host application 1412 and provide user data in response to the request data. The OTT connection 1450 may transfer both the request data and the user data. The client application 1432 may interact with the user to generate the user data that it provides. [0187] It is noted that the host computer 1410, base station 1420 and UE 1430 illustrated in Figure 14 may be identical to the host computer 1330, one of the base stations 1312a, 1312b, 1312c and one of the UEs 1391, 1392 of Figure 13, respectively. This is to say, the inner workings of these entities may be as shown in Figure 14 and independently, the surrounding network topology may be that of Figure 13. [0188] In Figure 14, the OTT connection 1450 has been drawn abstractly to illustrate the communication between the host computer 1410 and the use equipment 1430 via the base station 1420, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 1430 or from the service provider operating the host computer 1410, or both. While the OTT connection 1450 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). [0189] The wireless connection 1470 between the UE 1430 and the base station 1420 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1430 using the OTT connection 1450, in which the wireless connection 1470 forms the last segment. More precisely, the teachings of these embodiments may improve the radio resource utilization and thereby provide benefits such as reduced user waiting time. [0190] A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1450 between the host computer 1410 and UE 1430, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1450 may be implemented in the software 1411 of the host computer 1410 or in the software 1431 of the UE 1430, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1450 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 1411, 1431 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1450 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1420, and it may be unknown or imperceptible to the base station 1420. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 1410 measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software 1411, 1431 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1450 while it monitors propagation times, errors etc. [0191] Figure 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 15 will be included in this section. In a first step 1510 of the method, the host computer provides user data. In an optional substep 1511 of the first step 1510, the host computer provides the user data by executing a host application. In a second step 1520, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1530, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1540, the UE executes a client application associated with the host application executed by the host computer. [0192] Figure 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figure 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 16 will be included in this section. In a first step 1610 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1620, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1630, the UE receives the user data carried in the transmission. [0193] Figure 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 17 will be included in this section. In an optional first step 1710 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 1720, the UE provides user data. In an optional substep 1721 of the second step 1720, the UE provides the user data by executing a client application. In a further optional substep 1711 of the first step 1710, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 1730, transmission of the user data to the host computer. In a fourth step 1740 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure. [0194] Figure 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 18 will be included in this section. In an optional first step 1810 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 1820, the base station initiates transmission of the received user data to the host computer. In a third step 1830, the host computer receives the user data carried in the transmission initiated by the base station. [0195] Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [0196] It should be appreciated, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to actions and processes of a computer system, or a similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. [0197] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present disclosure as described herein. [0198] An embodiment of the present disclosure may be an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components. [0199] In the foregoing detailed description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the spirit and scope of the present disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. [0200] Throughout the description, some embodiments of the present disclosure have been presented through flow diagrams. It should be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present disclosure. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the spirit and scope of the present disclosure as set forth in the following claims. [0201] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.