WO2023139234A1

WO2023139234A1 - Technique for delivering a reference time

Info

Publication number: WO2023139234A1
Application number: PCT/EP2023/051428
Authority: WO
Inventors: Zhenhua Zou; Nianshan SHI
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-01-21
Filing date: 2023-01-20
Publication date: 2023-07-27

Abstract

A technique for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630) is described. As to a method (400) aspect of the technique performed by a network node (100; 1200; 1512; 1620), a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630) is determined (408). Responsive to the determining (408) of the degradation, a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630) is selectively transmitted (410). The network signal (800) is indicative of the reference time.

Description

TECHNIQUE FOR DELIVERING A REFERENCE TIME Technical Field The present disclosure relates to a technique for providing a reference time. More specifically, and without limitation, methods and devices are provided for delivering a reference time to a radio device. Background Radio communication systems operate according to radio access technologies (RATs) of the fifth generation (5G) and future sixth generation (6G), e.g. as specified by the Third Generation Partnership Project (3GPP). Such systems are collectively referred to as 5G systems (5GSs) herein. Future wireless services provided through radio devices (i.e., user equipments, UEs) served by 5GSs are expected to require a precise reference time for synchronous operation such as augmented reality, financial transactions in real time, and electrical power grids. The 3GPP document TR 22.878, version 18.2.0, discusses a Global Satellite Navigation System (GNSS) providing a time source for the core network (CN) of the 5GS, which may then provide this time reference and operate in a holdover state in case the GNSS time source is lost. For example, a 5GS-based timing can offer enhancements over 4G system, including resiliency to GNSS-received timing if GNSS fails or is compromised, e.g., integrated as alternative radio in each grandmaster clock or as an alternative grandmaster clock with 5G capability in a power sub-system. Alternatively to GNSS-use, the 5GS-based timing can be integrated with precision time protocol (PTP) grandmaster clock avoiding installation of external GNSS antenna and receiver at power sub-station. While the 3GPP document TR 22.878 requires that the 5GS shall support a mechanism to determine if there is degradation of the 5G time synchronization, this is discussed only for CN interaction. That is, the 3GPP document TR 22.878 discusses the ability of a network node (i.e., gNB) of a radio access network (RAN) of the 5GS to accurately track the 5GS clock, and the ability of the 5GS clock to track the Coordinated Universal Time (or French universel temps coordonné, UTC) or other timing sources. However, the ability of the RAN to deliver the 5GS clock has not been discussed and it is unclear how the 5GS can determine that there is a degradation in reference time delivery on the radio interface. Summary Accordingly, there is a need for a technique that enables a network node to deliver a reference time to a radio device when the radio device and/or the network node experience a degradation in the direct reception of a GNSS-based reference time. As to a first method aspect, a method performed by a network node for delivering a reference time to a radio device is provided. The method comprises or initiates determining a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The method further comprises or initiates, responsive to the determining of the degradation, selectively transmitting a network signal to the radio device. The network signal is indicative of the reference time. The first method aspect may be implemented alone or in combination with any one of the claims, particularly the claims 1 to 10. The first method aspect may be implemented at the network node (e.g., which may be a network node serving the radio device or a network node on which the radio device camps or a neighboring network node of the serving network node of the radio device). By selectively transmitting the network signal indicative of a reference time, the network node can deliver a timing source responsive to the degradation of a GNSS- based timing at the radio device, e.g., as an alternative or backup to the GNSS signal. The selectivity of the transmitting may comprise an assessment as to whether or not the time reference delivered through the network node meets, or is expected to meet, an accuracy requirement of the radio device (e.g., of a service provided at the radio device). The reference time (e.g., according to the GNSS signal at the radio device and/or the network signal from the network node) may be based on (e.g., provided by or derived from) the GNSS. The degradation of the GNSS signal at the radio device may comprise a loss of the GNSS signal at the radio device. Alternatively or in addition, the degradation of the GNSS signal at the radio device may comprise a malfunction (e.g., inaccuracy) or failure (e.g., outage) of one or more satellites of the GNSS. Alternatively or in addition, the degradation of the GNSS signal at the radio device may comprise a jamming of the GNSS signal. The network node may be a serving network node of the radio device. The network signal may be transmitted (e.g., broadcasted) to all radio devices (including the radio device) served by the network node or within a coverage area of the network node. The reference time delivered (i.e., provided) by or through the network node may also be referred to as network reference time (e.g., 5G reference time). The network signal (e.g., according to the first method aspect and/or that is indicative of the reference time) and/or a request message indicative of the degradation from the radio device received for the determining may comprise at least one of a radio resource control (RRC) signal (optionally comprising a reference time information element that is indicative of the reference time) and an assistance information (AI). The method (e.g., according to the first method aspect) may further comprise or initiate receiving a signal of a GNSS at the network node. The network signal may be derived from the signal of the GNSS at the network node. The selectivity of the transmission (e.g., according to the first method aspect) may depend on a result of a comparison between a required accuracy of the delivery of the reference time to the radio device and an achievable accuracy of the delivery of the reference time to the radio device. The required accuracy of the delivery of the reference time may correspond to a time synchronization error budget, e.g., of a radio interface between the network node and the radio device. Alternatively or in addition, the achievable accuracy of the delivery of the reference time may be determined by measuring a propagation delay, e.g., by measuring a round-trip time, between the network node and the radio device. The method (e.g., according to the first method aspect) may further comprise or initiate at least one of sending an accuracy report from the network node to a core network (CN) the accuracy report being indicative of an or the achievable accuracy of the delivery of the reference time; and sending a candidate message from the network node to a or the CN, the candidate message being indicative of one or more candidate network nodes for delivering the reference time with a or the required accuracy. The one or more candidate network nodes may comprise the network node and/or one or more neighboring network node of the network node. The network node (e.g., according to the first method aspect) may comprise a GNSS receiver for receiving a GNSS signal from a or the GNSS at the network node and/or deriving the network signal that is indicative of the reference time. Alternatively or in addition, the degradation of the GNSS signal is determined using the GNSS receiver at the network node. The degradation of the GNSS signal may be determined based on the network node observing (e.g., measuring) that the GNSS signal cannot be acquired at the network node or in a geographical area of the network node. The determining of the degradation of the GNSS signal (e.g., according to the first method aspect) may comprise receiving a request message from the radio device, the request message being indicative of the degradation of the GNSS signal at the radio device. The network signal may be selectively transmitted to the radio device responsive to the request message. The request message may be explicitly or implicitly indicative of the degradation of the GNSS signal (that is indicative of the reference time) at the radio device. For example, the request message may request the network node to transmitting the network signal to the radio device, wherein the request may be implicitly indicative of the degradation of the GNSS signal. The determining of the degradation of the GNSS signal (e.g., according to the first method aspect) may comprise receiving a control message from a or the CN, the control message being indicative of the degradation of the GNSS signal at the radio device. The network signal may be selectively transmitted to the radio device responsive to the control message. The control message may be explicitly or implicitly indicative of the degradation of the GNSS signal (that is indicative of the reference time) at the radio device. For example, the control message may request the network node to transmitting the network signal to the radio device, wherein the request may be implicitly indicative of the degradation of the GNSS signal. The control message may be received from an application function (AF) of the CN. The control message received (e.g., according to the first method aspect) from the CN may be indicative of the reference time. Alternatively or in addition, the control message is received from the CN responsive to a degradation report that is indicative of the degradation of the GNSS signal in a geographical area of the network node. The geographical area may comprise or correspond to a coverage area of the network node (e.g., for providing radio access to the radio device in the coverage area). Alternatively or in addition, the geographical area may be a terrestrial area. The network node and/or the radio device may send the degradation report to the CN (e.g., the AF). The selectively transmitting (e.g., according to the first method aspect) may further comprise sending a response to the core network, the response being indicative of whether or not the network node transmits the network signal indicative of the reference time to the radio device. For example, if the degradation is determined based on the control message from the CN requesting the network node to deliver the reference time, the response may be indicative of whether the network node accepts or rejects the request from the CN. As to a second method aspect, a method performed by a radio device for receiving a reference time from a network node is provided. The method comprises or initiates determining a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. Alternatively or in addition, the method comprises or initiates (e.g., upon the determining of the degradation) receiving a network signal from the network node. The network signal is indicative of the reference time. The second method aspect may be implemented alone or in combination with any one of the claims, particularly the claims 11 to 14. The second method aspect may be implemented at the radio device (e.g., served by or connected to or camping on the network node). The second method aspect may further comprise any feature and/or any step disclosed in the context of the first method aspect, or a feature and/or step corresponding thereto, e.g., a receiver counterpart to a transmitter feature or step, or a transmitter counterpart to a receiver feature or step, or a network counterpart to a radio device feature or step. By receiving the network signal, the radio device can use the reference time in the network signal as a backup time source or an alternative timer source or a holdover time source, e.g., while an accuracy and/or signal quality of GNSS signal does not meet a required accuracy. The network signal being indicative of the reference time may be received from the network node proactively transmitting the network signal upon also (e.g., independently and/or in coincidence) determining the degradation of the GNSS signal. Alternatively or in addition, the network signal being indicative of the reference time may be received responsive to a request message transmitted by the radio device. The determining of the degradation of the GNSS signal (e.g., according to the second method aspect) may comprise transmitting a request message from the radio device to at least one of the network node and the core network, the request message being indicative of the determined degradation of the GNSS signal at the radio device. The network signal may be received responsive to the request message. The radio device (e.g., according to the second method aspect) may comprise a GNSS receiver for receiving a GNSS signal from the GNSS at the radio device and/or deriving the reference time. Alternatively or in addition, the degradation of the GNSS signal is determined using the GNSS receiver at the radio device. The method may comprise the step of receiving or attempting to receive (e.g., monitor) the GNSS signal from the GNSS, e.g., as a sub-step of the step of determining. The method (e.g., according to the second method aspect) may further comprise any one of features or steps of the first method aspect. As to a third method aspect, a method performed by a core network for delivering a reference time to a radio device is provided. The method comprises or initiates determining a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The method further comprises or initiates, responsive to the determining of the degradation, requesting a network node to transmit a network signal to the radio device. The network signal is indicative of the reference time. The third method aspect may be implemented alone or in combination with any one of the embodiments or claims, particularly the claims 15 to 20. The third method aspect may further comprise any feature and/or any step disclosed in the context of the first and/or second method aspect, or a feature and/or step corresponding thereto, e.g., a network counterpart (or CN counterpart) to a radio device feature or step. By requesting a network node to transmit the network signal indicative of the reference time to the radio device, the core network (e.g., an application function, AF, and/or an Access and Mobility Management Function, AMF) can initiate delivering the reference time responsive to a request of the radio device or a report that the GNSS signal is unavailable in a geographical area of the radio device. Alternatively or in addition, the CN (e.g., the AMF and/or the AF) can coordinate the delivering of the reference time, e.g., by collecting data as to the required accuracy (e.g., for the service provided by the radio device) and/or the achievable accuracy (e.g., of one or more candidate network nodes, optionally including the network node) and/or by selecting the network node that is requested to transmit the network signal to the radio device. The radio device may be served by the network node. Alternatively or in addition, the network node may be connected to the core network. The method (e.g., according to the third method aspect) may further comprise or initiate selecting the network node or another candidate network node to be requested to transmit the network signal to the radio device. The network node and/or another candidate network node to be requested (to transmit the network signal to the radio device) may be selected by the core network. The method (e.g., according to the third method aspect) may further comprise at least one of receiving an accuracy report from at least one or each of the network node and another or the other candidate network node, the accuracy report being indicative of an achievable accuracy of the delivery of the reference time using the respective network node; and receiving a candidate message from the network node, the candidate message being indicative of one or more candidate network nodes for delivering the reference time with a required accuracy. The one or more candidate network nodes may comprise the network node (e.g., prior to rejecting or after accepting the request. Alternatively or in addition, the one or more candidate network nodes may not comprise the network node, e.g., after rejecting the request. The network node or the other candidate network node (e.g., according to the third method aspect) may be selected among the indicated one or more candidate network nodes and/or based on comparing the accuracy reports. The method (e.g., according to the third method aspect) may further comprise receiving a response from the network node to the requesting, the response being indicative of whether or not the network node transmits the network signal indicative of the reference time to the radio device. The selecting of another candidate network node may be triggered by receiving the response indicating a rejection of the request (i.e., indicating of the network node not transmitting the network signal indicative of the reference time to the radio device). The method (e.g., according to the third method aspect) may further comprising any one of features or steps of the first method aspect or the second method aspect. As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the method aspects disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and/or the host computer. Alternatively, or in addition, the method may be encoded in a Field-Programmable Gate Array (FPGA) and/or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language. As to a first device aspect, a network node for delivering a reference time to a radio device is provided. The network node comprising memory operable to store instructions and processing circuitry (e.g., at least one processor and a memory) operable to execute the instructions, such that the network node is operable to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The network node is further operable to responsive to the determining of the degradation, selectively transmit a network signal to the radio device, the network signal being indicative of the reference time. The network node (e.g., according to the first device aspect) may further be operable to perform any one of the steps of the first method aspect. As to another first device aspect a network node for delivering a reference time to a radio device is provided. The network node is configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The network node is further configured to responsive to the determining of the degradation, selectively transmit a network signal to the radio device, the network signal being indicative of the reference time. The network node (e.g., according to the first device aspect) may be further configured to perform any one of the steps of the first method aspect. As to another first device aspect, a base station for delivering a reference time to a UE is provided. The base station is configured to communicate with the UE. The base station comprises a radio interface and processing circuitry (e.g., at least one processor and a memory) configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the UE. The base station is further configured to responsive to the determining of the degradation, selectively transmit a network signal to the UE, the network signal being indicative of the reference time. The base station (e.g., according to the first device aspect) and/or its processing circuitry may be further configured to execute any one of the steps of the first method aspect. As to a second device aspect, a radio device for receiving a reference time from a network node is provided. The radio device comprises memory operable to store instructions and processing circuitry (e.g., at least one processor and a memory) operable to execute the instructions, such that the radio device is operable to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The radio device is further operable to – upon the determining of the degradation – receive a network signal from the network node, the network signal being indicative of the reference time. The radio device (e.g., according to the second device aspect) may be further operable to perform any one of the steps of the second method aspect. As to another second device aspect, a radio device for receiving a reference time from a network node is provided. The radio device is configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The radio device is further configured to upon the determining of the degradation, receive a network signal from the network node, the network signal being indicative of the reference time. The radio device (e.g., according to the second device aspect) may be further configured to perform any one of the steps of the second method aspect. As to another second device aspect, a user equipment (UE) for receiving a reference time from a network node is provided. The UE is configured to communicate with a base station or with a radio device functioning as a gateway. The UE comprises a radio interface and processing circuitry (e.g., at least one processor and a memory) configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the UE. The UE is further configured to, upon the determining of the degradation, receive a network signal from the base station, the network signal being indicative of the reference time. The UE (e.g., according to the second device aspect) and/or its processing circuitry may be further configured to execute any one of the steps of the second method aspect. As to a third device aspect, a core network (CN) or CN node for delivering a reference time to a radio device is provided. The CN or CN node comprises memory operable to store instructions and processing circuitry (e.g., at least one processor and a memory) operable to execute the instructions, such that the CN or CN node is operable to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The CN or CN nose is further operable to responsive to the determining of the degradation, request a network node to transmit a network signal to the radio device, the network signal being indicative of the reference time. The CN or CN node (e.g., according to the third device aspect) may be further operable to perform any one of the steps of the third method aspect. As to another third device aspect a core network (CN) or CN node for delivering a reference time to a radio device is provided. The CN or CN node is configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The CN or CN node is further configured to responsive to the determining of the degradation, request a network node to transmit a network signal to the radio device, the network signal being indicative of the reference time. The CN or CN node (e.g., according to the third device aspect) may be further configured to perform any one of the steps of the third method aspect. As to another third device aspect, an application function (AF) for delivering a reference time to a radio device is provided. The AF is configured to communicate with a user equipment (UE) through a base station. The AF comprising a network interface and processing circuitry (e.g., at least one processor and a memory) configured to determine a degradation of a Global Navigation Satellite System (GNSS) signal indicative of the reference time at the radio device. The AF is further configured to, responsive to the determining of the degradation, request the base station to transmit a network signal to the UE, the network signal being indicative of the reference time. As to a still further aspect a communication system including a host computer is provided. The host computer comprises a processing circuitry configured to provide user data, e.g., requiring or included the positioning and/or the PDC for time synchronization. The host computer further comprises a communication interface configured to forward the user data to a cellular network (e.g., the CN and/or the AM and/or the AMF and/or the RAN and/or the network node) for transmission to a UE as the radio device. A processing circuitry of the cellular network is configured to execute any one of the steps of the first and/or third method aspects. Alternatively or in addition, the UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the second method aspects. The AF (e.g., according to the third device aspect) and/or its processing circuitry may be further configured to execute any one of the steps of the third method aspect. As to a system aspect, a communication system is provided. The communication system includes a host computer comprising processing circuitry (e.g., at least one processor and a memory) configured to provide user data and a communication interface configured to forward user data to a cellular radio network (or an ad hoc radio network) for transmission to a user equipment (UE) is provided. The UE may comprise a radio interface and processing circuitry (e.g., at least one processor and a memory). The processing circuitry of the UE may be configured to execute any one of the steps of the second method aspect. The communication system (e.g., according to the system aspect) may further include the UE. Alternatively, or in addition, the cellular network may further include one or more base stations or servers configured for radio communication with the UE and/or to provide a data link between the UE and the host computer using the first and/or second and/or third method aspects. In the communication system (e.g., according to the system aspect), the radio network may further comprise a base station, or a radio device functioning as a gateway, which is configured to communicate with the UE. The base station, or the radio device functioning as a gateway, may comprise processing circuitry (e.g., at least one processor and a memory), which is configured to execute any one of the steps of the first method aspect and/or the third method aspect. In the communication system (e.g., according to the system aspect), the processing circuitry of the host computer may be configured to execute a host application, thereby providing the user data. Alternatively, or in addition, the processing circuitry of the UE may be configured to execute a client application associated with the host application. In any aspect, the reference time delivered by means of the network signal may also be based on a GNSS signal (e.g., from the same GNSS formerly used by the radio device) received at any location (e.g., other than a location of the radio device experiencing the degradation of the GNSS signal), e.g., at any location in a network supporting the network node, at the network node, at another network node (e.g., a neighboring network node) of a radio access network (RAN) comprising the network node time, at another radio device connected to the network node, or in a core network (CN) connected to the network node and/or the RAN. Alternatively or in addition, the reference time delivered by means of the network signal may be based on a backup clock or holdover clock operated directly or indirectly connected to the network node, e.g., a clock at the network node, a clock at another network node (e.g., a neighboring network node) of the RAN comprising the network node time, a clock at another radio device connected to the network node, or a clock in the CN connected to the network node and/or the RAN. Independent of a time source underlying the reference time delivered by means of the network signal, the reference time delivered by means of the network signal may be referred to as network reference time (e.g., as a 4G reference time or 5G reference time or 6G reference time). In any aspect, the delivering of the reference time by means of the network signal may support timing resilience (i.e.: timing resiliency). Any aspect may be implemented as a (e.g., 5G or 6G system) support for timing resilience, and/or a (e.g., 5G or 6G) system clock, and/or an accurate reference time delivery, and/or a propagation delay compensation (PDC). Alternatively or in addition, any aspect may be implemented as method of signaling (e.g., reporting) a (e.g., 5G or 6G) timing synchronization status to the radio device and/or to the CN (e.g., the AF or AMF). Embodiments of the technique can fulfill requirements set out in the 3GPP document R1-1901470, "Reply LS on TSN requirements evaluation", RAN1, 3GPP TSG-RAN WG1 Ad-Hoc Meeting 1901 Taipei, Taiwan, January 21st to 25th, 2019. The technique may be implemented in accordance with a 3GPP specification, e.g., for 3GPP release 17 or 18. The technique may be implemented for 3GPP Long Term Evolution (LTE or 4G) or 3GPP New Radio (NR or 5G) based on, or according to a modification of, the 3GPP document TS 38.413, version 16.8.0; TS 38.423, version 16.8.0; TS 38.473, version 16.8.0; TS 38.331, version 16.7.0; 3GPP TS 23.501, version 17.3.0; and/or 3GPP TS 23.502, version 17.3.0. Alternatively or in addition, embodiments of the technique can fulfill requirements set out in the 3GPP document TR 22.878, version 18.2.0; and/or R1-1901470. The radio device and/or the network node and/or the CN (e.g., the AM or AMF) may form, or may be part of, a radio network, e.g., according to the Third Generation Partnership Project (3GPP) such as 5GS or according to the standard family IEEE 802.11 (Wi-Fi). The first method aspect, the second method aspect and third method aspect may be performed by one or more embodiments of the network node (e.g., a base station such as eNB or gNB), the radio device (e.g., a UE), and the CN (e.g., AF or AMF), respectively. The RAN may comprise one or more base stations, e.g., performing the first method aspect. Alternatively or in addition, the radio network may be a vehicular, ad hoc and/or mesh network comprising two or more radio devices, e.g., acting as a remote radio device and/or a relay radio device performing the first and/or second method aspects, respectively. Any of the radio devices may be a 3GPP user equipment (UE) or a Wi-Fi station (STA). The radio device may be a mobile or portable station, a device for machine- type communication (MTC), a device for narrowband Internet of Things (NB-IoT) or a combination thereof. Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle. Examples for the portable station include a laptop computer and a television set. Examples for the MTC device or the NB-IoT device include robots, sensors and/or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-IoT device may be implemented in a manufacturing plant, household appliances and consumer electronics. Whenever referring to a core network (CN), the CN may be implemented by one or more nodes embodying at least one of an application function (AF), an access and mobility management function (AMF), and user plane function (UPF). Whenever referring to a radio access network (RAN), the RAN may be implemented by one or more embodiments of a network node (e.g., base station). The radio device may be wirelessly connected or connectable (e.g., according to a radio resource control, RRC, state or active mode) with at least one network node of the RAN. The network node (e.g., base station) may encompass any station that is configured to provide radio access to any of the radio devices. The base stations may also be referred to as a cell, a beam, a transmission and reception point (TRP), a radio access node, or an access point (AP). The network node and/or the radio device may provide a data link to a host computer providing user data to the radio device or gathering user data from the radio device. Examples for the network node may include a 3G base station or Node B (NB), 4G base station or eNodeB (eNB), a 5G base station or gNodeB (gNB), a Wi-Fi AP, and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave). The RAN and/or the CN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or 3GPP New Radio (NR). Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, and/or a Radio Resource Control (RRC) layer of a protocol stack for the radio communication. Alternatively or in addition, any aspect of the technique may be implemented using a midhaul interface (e.g., an F1 interface) in the network node and/or a non-access stratum (NAS) interface (e.g., an N1 or N2 interface) between the network node and the core network (e.g., the AM or the AMF). Herein, referring to a protocol of a layer may also refer to the corresponding layer in the protocol stack. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method. Any one of the devices, the radio device (e.g., UE), the network node (e.g., base station), the CN (e.g., AN node or AMF node), the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa. Particularly, any one of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspects. Brief Description of the Drawings Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein: Fig.1 shows a schematic block diagram of an embodiment of a device for delivering a reference time to a radio device, which may be implemented in a network node; Fig.2 shows a schematic block diagram of an embodiment of a device for receiving a reference time from a network node, which may be implemented in a radio device; Fig.3 shows a schematic block diagram of an embodiment of a device for delivering a reference time to a radio device, which may be implemented in a core network; Fig.4 shows a flowchart for a method of delivering a reference time to a radio device, which method may be implementable by the device of Fig.1; Fig.5 shows a flowchart for a method of receiving a reference time from a network node, which method may be implementable by the device of Fig.2; Fig.6 shows a flowchart for a method of delivering a reference time to a radio device, which method may be implementable by the device of Fig.3; Fig.7 schematically illustrates an example of a radio network comprising embodiments of the devices of Figs.1, 2, and 3 for performing the methods of Figs.4, 5, and 6, respectively; Fig.8 schematically illustrates an example of delivering a reference time from the device of Fig.1 to the device of Fig.2; Fig.9 schematically illustrates a signaling diagram resulting from embodiments of the devices of Figs.1 and 2 performing the methods of Figs.4 and 5, respectively, in radio communication; Fig.10 schematically illustrates a signaling diagram for delivering a reference time to a radio device, which may use any one of the methods of Figs.4, 5, and 6; Fig.11 schematically illustrates a signaling diagram for delivering a reference time to a radio device, which may use any one of the methods of Figs.4 and 6; Fig.12 shows a schematic block diagram of a network node embodying the device of Fig.1; Fig.13 shows a schematic block diagram of a radio device embodying the device of Fig.2; Fig.14 shows a schematic block diagram of a core network or core network node embodying the device of Fig.3; Fig.15 schematically illustrates an example telecommunication network connected via an intermediate network to a host computer; Fig.16 shows a generalized block diagram of a host computer communicating via a base station or radio device functioning as a gateway with a user equipment over a partially wireless connection; and Figs.17 and 18 show flowcharts for methods implemented in a communication system including a host computer, a base station or radio device functioning as a gateway and a user equipment. Detailed Description In the following description, for purposes of explanation and not limitation, specific details are set forth, such as a specific network environment in order to provide a thorough understanding of the technique disclosed herein. It will be apparent to one skilled in the art that the technique may be practiced in other embodiments that depart from these specific details. Moreover, while the following embodiments are primarily described for a New Radio (NR) or 5G implementation, it is readily apparent that the technique described herein may also be implemented for any other radio communication technique, including a Wireless Local Area Network (WLAN) implementation according to the standard family IEEE 802.11, 3GPP LTE (e.g., LTE-Advanced or a related radio access technique such as MulteFire), for Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4. Moreover, those skilled in the art will appreciate that the functions, steps, units and modules explained herein may be implemented using software functioning in conjunction with a programmed microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP) or a general purpose computer, e.g., including an Advanced RISC Machine (ARM). It will also be appreciated that, while the following embodiments are primarily described in context with methods and devices, the invention may also be embodied in a computer program product as well as in a system comprising at least one computer processor and memory coupled to the at least one processor, wherein the memory is encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein. Fig.1 schematically illustrates a block diagram of an embodiment of a device for delivering a reference time to a radio device, e.g., in a radio access network (RAN). The device is generically referred to by reference sign 100. The device 100 comprises a degradation determining module 108 that performs a determining step of the first method aspect and a reference time transmission module 110 that performs a selectively-transmitting step of the first method aspect. Any of the modules of the device 100 may be implemented by units configured to provide the corresponding functionality. The device 100 may also be referred to as, or may be embodied by, the network node (e.g., gNB or gNB-CU). The network node 100 may be in (e.g., wired or wireless) communication with the CN (e.g., the AF and/or the AMF) and/or in wireless communication with the radio device, e.g., for the transmitting of the network signal. The radio device may be embodied by the below device 200. Fig.2 schematically illustrates a block diagram of an embodiment of a device for receiving a reference time from a network node, e.g., in a radio access network (RAN). The device is generically referred to by reference sign 200. The device 200 comprises a degradation determining module 208 that performs a determining step of the second method aspect and a reference time receiving module 210 that performs a receiving step of the second method aspect. Any of the modules of the device 200 may be implemented by units configured to provide the corresponding functionality. The device 200 may also be referred to as, or may be embodied by, the radio device (e.g., UE). The radio device 200 may be in communication with the CN (e.g., an AF or AMF) and/or the network node, e.g., for the receiving of network signal. The network node may be embodied by the above device 100. The CN (e.g., the AM or AMF) may be embodied by the below device 300. Fig.3 schematically illustrates a block diagram of an embodiment of a device for delivering (e.g., initiating delivery of) a reference time to a radio device, e.g., in a radio access network (RAN). The device is generically referred to by reference sign 300. The device 300 comprises a degradation determining module 301 that performs a determining step of the third method aspect and a node requesting module 308 that performs a requesting step of the third method aspect. Any of the modules of the device 300 may be implemented by units configured to provide the corresponding functionality. The request may also be referred to as CN request (as it may be sent by the CN). The device 300 may also be referred to as, or may be embodied by, the CN, i.e., one or more (e.g., functional) nodes of the CN, e.g., the AF or the AMF. The CN 300 may be in communication with the radio device and/or the network node, e.g., for receiving a radio device request and/or transmitting the CN request, respectively. The network node may be embodied by the above device 100. The radio device may be embodied by the above device 200. Fig.4 shows an example flowchart for a method 400 according to the first method aspect. The method 400 comprises the steps 408 and 410 indicated in Fig.4. The method 400 may be performed by the device 100. For example, the modules 108 and 110 may perform the steps 408 and 410, respectively. Fig.5 shows an example flowchart for a method 500 according to the second method aspect. The method 500 comprises the steps 508 and 510 indicated in Fig.5. The method 500 may be performed by the device 200. For example, the modules 208 and 210 may perform the steps 508 and 510, respectively. Fig.6 shows an example flowchart for a method 600 according to the second method aspect. The method 600 comprises the step 601 and 608 indicated in Fig.6. The method 600 may be performed by the device 300. For example, the module 301 and 308 may perform the step 601 and 608, respectively. In any aspect, the technique may be applied to uplink (UL), downlink (DL) or direct communications between radio devices, e.g., device-to-device (D2D) communications or sidelink (SL) communications. Each of the device 200 and device 100 may be a radio device or a network node (i.e., a base station, e.g., gNB or eNB). Herein, any radio device may be a mobile or portable station and/or any device wirelessly connectable to a base station or RAN, or to another radio device. For example, the radio device may be a user equipment (UE), a device for machine-type communication (MTC) or a device for (e.g., narrowband) Internet of Things (IoT) or industrial IoT (IIoT). Two or more radio devices may be configured to wirelessly connect to each other, e.g., in an ad hoc radio network or via a 3GPP SL connection. Furthermore, any network node may be a node or station providing radio access to radio device, may be part of a radio access network (RAN) and/or may be a node connected to the RAN for controlling the radio access. For example, the base station may be an access point, for example a Wi-Fi access point. Hereinbelow, while a 5G system is described for concreteness, any other radio access technology (RAT), e.g., 4G, 5G or 6G can be applied as well. Accordingly, a gNB is used to describe examples of the network node 100, which may also be implemented by any other network node such as an eNB. The CN node 300 is described using the non-limiting example of an AF or AMF. Moreover, the radio device 200 is described as a UE. Herein, GNSS time may refer to the reference time (e.g., based on a GNSS). Alternatively or in addition, GNSS source may refer to the GNSS signal. The technique may comprise one or more signaling methods (e.g., any one of the methods 400, 500, and 600) to deliver (i.e., provide) or support delivering the reference time (e.g., the GNSS time) from the gNB 100 to the UE 200 due (e.g., responsive to) a degradation (e.g., a loss) of the GNSS signal (i.e., a GNSS source) at the UE 200, e.g., when it is determined in the step 408, 508 or 601 that the UE 200 cannot (or likely cannot) receive the reference time based on the GNSS signal from satellites of the GNSS. Alternatively or in addition, the methods may comprise at least one of the following three categories. As to a first category, the request to provide the GNSS time (i.e., to deliver the reference time) to the UE 200 is initiated 608 by the core network (CN) 710 (i.e., by a CN node 300, e.g., the AF), optionally wherein the UE 200 has requested so in a non-access stratum (NAS) signaling (i.e., in the UE request) to the Application Function (AF). The gNB 100 may accept or reject the request (e.g., according to the selectivity in the step 410), e.g., based on a comparison between a required time delivery accuracy and an achievable time delivery accuracy. Alternatively or in addition, the gNB 100 may further provide (i.e., send) the best achievable time delivery accuracy to the CN 710 (e.g., to the CN node 300). Alternatively or in addition, the gNB 100 may further provide the best candidate gNBs to fulfill the requirement. As to a second category, the gNB 100 provides the GNSS time to the UEs within its coverage, based on gNB’s observation (e.g., the determining 408) that the GNSS source cannot be acquired in its geographical area, assuming gNB 100 is also equipped with GNSS receivers, for example, the satellite is down or the satellite signal is jammed. The gNB 100 performs the delivering of the reference time according to a pre-defined accuracy level and/or based on subscription information of the UE 200. As to a third category, the UE 200 may request (i.e., ask) the gNB 100 to provide GNSS time in an UL RRC message (e.g., UE assistance information message) in the steps 508 and 408, respectively. This is used in case a GNSS receiver of the UE 200 malfunctions. Fig.7 schematically illustrates an example of a radio network 700 comprising embodiments of the application function (AF) 300 in a core network (CN) 710, the gNB 100 in a RAN 720, and a UE 200. The gNB 100 may be split (e.g., physically and/or functionally) in a gNB central unit (CU) 100-CU and one or more gNB distributed units (DUs) 100-DU. The gNB 100 and/or the gNB-DUs 100-DU may act as transmission and receptions points (TRPs), e.g., for transmitting the network signal indicative of the reference time 800 in the step 410. Any embodiment may be implemented to provide (i.e., deliver) a time synchronization, e.g., a (e.g., 5G) system internal synchronization. The use of time synchronization has been common practice already for cellular networks of different generations and is an integral part of operating 5G cellular radio systems. The 5G radio network components themselves are also time synchronized, e.g., for advanced radio transmission, such as synchronized Time Division Duplex (TDD) operation, cooperative multipoint (CoMP) transmission, or carrier aggregation. A 5G capability introduced for integrating 5G systems and Time-Sensitive Networking (TSN) networks is delivery of (i.e., the delivering) a 5G- internal clock (i.e., the reference time) to the radio device 200, e.g. as a service over the 5G system (5GS) 700. Providing a time synchronization may comprise at least one of the following steps: - Once the (e.g., 5G) reference time is acquired by a gNB 100 (e.g. from a GPS/GNSS receiver), the reference time is transmitted to different nodes (e.g., other gNBs 100 or units of the gNB or the other gNBs 100-CU and/or 100-DU) in the 5GS as an example of a radio network 700, e.g., with the goal of introducing as little synchronicity error (e.g., uncertainty) as possible when distributing it. - The distribution of 5G reference time information to UEs 200 is designed to exploit the existing synchronized operation inherent to the 5G RAN 720. - Such a building block approach enables end-to-end time synchronization for industrial applications communication services running over 5G system 700. The gNB 100 maintains the acquired 5G reference time on an ongoing basis as well as periodically projecting the value it will have when a specific reference point in the system frame structure (e.g. at the end of SFN_z) occurs at the gNB Antenna Reference Point (ARP), which is generically referred to as a reference point t_R in Fig.8. The transmission 410 of the network signal 800 indicative of the reference time (i.e., the time synchronization) may comprise at least one of the following steps or sub-steps of the step 410: - A radio resource control (RRC) broadcast message (e.g., a system information block, SIB) or RRC unicast message containing a projected reference time value and a corresponding reference point (e.g., the value of SFN_z) is transmitted during a first system frame number (e.g., labeled SFN_x) and received by the UE 200 in advance of t_R. Optionally, the network signal 800 is broadcasted to all or multiple UEs 200 in SIB9 or unicast-transmitted to one or more individual UEs 200 in the RRC message DLInformationTransfer. - The message used to send the 5G reference time information may also contain an uncertainty value to indicate to the UE the expected error (uncertainty) that the indicated 5G reference time value (applicable to the reference point t_R) is expected to have. Optionally, the uncertainty value reflects (a) the accuracy with which an implementation of the gNB 100 can ensure that the indicated reference time corresponding to reference point t_R (e.g., the end of SFN_z) will reflect the actual time when that reference point occurs at the ARP (e.g., due to uncertainty in a propagation delay), and/or (b) the accuracy with which the reference time can be acquired by the gNB 100. The uncertainty introduced by (a) is implementation specific but is expected to be negligible and is therefore not further considered. Fig.8 schematically illustrates transmissions including an embodiment of the transmission 410 (e.g. of a system frame number, SFN) of the gNB 100. The reference time information may be transmitted in the RRC information element (IE) ReferenceTimeInfo as an example of the network signal 800. Exemplary details are shown below using Abstract Syntax Notation One (ANS.1) as an interface description language for defining an embodiment of the ReferenceTimeInfo information element.

One or more of the fields of the ReferenceTimeInfo IE may be implemented according to the following description.

Any embodiment may implement at least one of the following features or steps of a propagation delay compensation (PDC), e.g. to achieve an achievable accuracy in the delivery 410 of the reference time that fulfils a required accuracy. In an industrial use case where the provision of industrial clock synchronization service is supported through the 5G system, the 5G system is in practice only allowed to contribute a portion of the maximum end-to-end synchronicity budget (uncertainty budget) allowed for any given TSN grandmaster clock (GM clock). There are many uncertainty components in the 5G system 700, including the UE internal synchronization error budget, and the synchronization error budget associated with delivering the 5G internal clock to the user plane function (UPF) and the UE 200. The biggest 5GS synchronization error introduced may occur when the 5G internal clock is delivered to the UE 200 from the gNB 100 via the radio interface (e.g., the Uu interface). It occurs on the radio interface (also referred to as Uu interface or colloquially as “air interface”) and is due to the error from unknown propagation delays. In some large cells, the propagation delay from the gNB 100 to the UE 200 can be 1 µs (i.e., 1 microsecond) or greater (i.e., the distance from the gNB 100 to the UE is 300 meters or more). The range of uncertainty for the most demanding synchronization requirement for a single Uu interface shown in below table below was agreed at 3GPP TSG-RAN WG2 #113-e to meet performance requirements. Two scenarios are listed to represent a general wide area deployment and a local deployment area. Examples of the time synchronization error budget for a single Uu interface:

In 3GPP Release 15 or 16, the legacy UL transmission timing adjustment (i.e., timing advanced, TA) can be re-used to estimate and compensate the propagation delay.3GPP Timing Advance (TA) command is utilized in cellular communication for uplink transmission synchronization and it is an implementation variant of a round-trip time (RTT) measurement. Theoretically, the dynamic part of the TA, i.e., N_TA is equal to (2 x propagation delay) considering the same propagation delay value applies to both downlink and uplink directions. Since the TA command is transmitted to the UE mainly via the MAC control element (CE), the UE can derive the propagation delay. The challenges of the TA method are that due to various implementation inaccuracies in transmit timing and reception timing at gNB and UE, the TA method can introduce up to 540 ns uncertainty to determine the downlink propagation delay on a single Uu interface based on requirements for an implementation according to 3GPP Release 15 or 16 and/or 3GPP document R1- 1901470, "Reply LS on TSN requirements evaluation", RAN1, 3GPP TSG-RAN WG1 Ad-Hoc Meeting 1901 Taipei, Taiwan, January 21-25, 2019. In 3GPP Release 17, the RAN work item “Enhanced Industrial Internet of Things (IoT) and ultra-reliable and low latency communication (URLLC) support for NR” has introduced a propagation delay compensation method. The method is to leverage the legacy multi-RTT positioning method. This legacy method makes use of, e.g., the UE Rx-Tx time difference measurements and DL-PRS-RSRP of downlink signals received from multiple transmission reception points (TRPs) measured by the UE, and the measured gNB Rx-Tx time difference measurements and UL-SRS- RSRP at multiple TRPs of uplink signals transmitted from the UE. The measurements are used to determine the RTT at the positioning server which are used to estimate the location of the UE. Fig.9 schematically illustrates a signaling diagram of measuring 900 a round-trip time (RTT), e.g., for an RTT-based propagation delay compensation (PDC). The RTT-based method of delay compensation (e.g., introduced in 3GPP Release 17) leverages (e.g., uses) the legacy multi-RTT positioning method and/or at least one of the following steps: (a) The UE 200 transmits a reference signal (e.g., an uplink sounding RS, UL SRS) in an uplink frame i and records the transmission time as t_1. (b) The gNB 100 receives uplink frame i and records the time of arrival of the first detected path as t_3. (c) The gNB 100 transmits a reference signal (e.g., DL PRS or CSI-RS for tracking (TRS)) in a downlink frame j to the UE 200, and records transmission time as t_2. (e) The UE 200 receives downlink frame j and records the time of arrival of the first detected path as t_4. (d) The following calculations are performed, e.g., in the UE 200 and gNB 100, respectively: (i) UE _Rx-Tx diff = t₄ - t₁; (ii) gNB _Rx-Tx diff = t₃ - t₂. This quantity can be positive or negative depending on the whether gNB transmits the DL frame before or after receiving the UL frame. (e) A propagation delay can be calculated as follows: round-trip time (RTT) = (gNB Rx – Tx time difference) + (UE Rx – Tx time difference). It is noted that the time differences have opposite signs, e.g., as illustrated in Fig.9. The propagation delay is one half of the RTT. The method 900 may be implemented using at least one of the following variants, e.g., depending on which node (e.g., gNB 100 or UE 200) calculates the RTT. The other node may deliver its Rx-TX difference: 1. UE-side propagation delay compensation: The gNB 100 delivers the gNB Rx- Tx time difference to the UE 200 and the UE 200 calculates the round-trip time RTT to obtain the propagation delay. 2. gNB-side propagation delay compensation: The UE 200 delivers the UE Rx- Tx time difference to the gNB and the gNB calculates the round-trip time RTT to obtain the propagation delay. Any embodiment may receive the time synchronization budget on (e.g., for) the Uu interface as follows. It has some benefits for the NG-RAN 720 (e.g., the gNB 100) to receive a time synchronization error budget (briefly: error budget) available for the NG-RAN 720 (e.g., available for the gNB) and/or for the radio (i.e., Uu) interface, e.g. according to the 3GPP document R2-2106560. The rationale is for the NG-RAN 720 to appropriately configure radio resources for each UE 200 to achieve the time synchronization error budget. E.g., the delivery (e.g., the transmission 410) of the reference time (e.g., the selectivity in the step 410) may follow at least one of the following case: 1. In the case that the error budget is generally much larger than the maximum radio wave propagation delay in a cell, there is no need for NG- RAN to configure propagation delay compensation; 2. In the case that the error budget is, e.g., around 500 ns or larger, then the NG-RAN can configure legacy TA-based propagation delay compensation. The legacy TA-based propagation delay compensation does not require separate reference signals configurations as in the RTT-based propagation delay compensation nor any additional information exchange (as it is carried in the legacy timing advance MAC CE); 3. In the case that the error budget is, e.g., below 500 ns, then the NG-RAN must configure RTT-based propagation delay compensation. The more stringent the error budget is, the more radio bandwidths (e.g., more frequent reference signals, more repetitions) are needed for the reference signals used for the propagation delay compensation. Consequently, it is specified in the 3GPP document TS 23.501, version 17.3.0, clause 5.27.1.9, that the Application Function (AF) may request to use the 5G access stratum (AS) as a time synchronization distribution method, which may be used for, or extended according to, the method 600. Optionally, the AF may include the time synchronization error budget in the request. (e.g., the CN request in the step 608, which may also be referred to as AF request). If the AF includes the time synchronization error budget (or briefly: error budget) in the AF request, a time sensitive communication time synchronization function (TSCTSF) derives the error budget available for the NG-RAN 720 (e.g., available for the gNB 100) to provide the 5GS access stratum time to each targeted UE 200 via the Uu interface (also referred to as Uu time synchronization error budget hereafter). The TSCTSF uses the time synchronization error budget provided by AF (directly or via a network exposure function, NEF) in order to derive the Uu time synchronization error budget. To derive the Uu time synchronization error budget for each targeted UE 200, the TSCTSF takes the following into account: - a selected time synchronization distribution method, e.g., a 5G access stratum time distribution and/or a time distribution based on a (generalized) Precision Time Protocol, or (g)PTP; - whether 5GS operates as a boundary clock and acts as a GM clock, and/or whether a clock connected to a device-side TSN translator (DS-TT) and/or a network-side TSN translator (NW-TT) acts as GM clock in case of (g)PTP based time distribution; - PTP port states in case of (g)PTP based time distribution; - parts of the time synchronization error budget at the CN 710 and/or the UE 200 (which may be predefined, or calculated by the 5GS 700 by means that are based on implementation). If the AF has not included a time synchronization error budget, the TSCTSF uses a preconfigured time synchronization error budget to derive the Uu time synchronization error budget. TSCTSF provides a time distribution indication and the Uu time synchronization error budget to NG-RAN as described in clause 4.15.9.4 of the 3GPP document TS 23.502, version 17.3.0. Based on this, NG-RAN provides the 5GS access stratum time to the UE according to the Uu interface time synchronization error budget as provided by the TSCTSF (if supported by UE and NG-RAN). In any embodiment of the gNB 100 or the method 400, the gNB 100 may be split in the CU and one or more DU (e.g., each acting as a TRP). This gNB split architecture may be used for the reference time delivery 410. In the gNB split architecture, the gNB-CU 100-CU receives information over a next generation application protocol (NGAP) on the N2 interface. The SIBs are distributed to the gNB-DU 100-DU over an F1 application protocol (F1AP) on the F1 interface. The gNB-DU 100-DU handles the scheduling and transmission to the Uu interface. For the RRC broadcast message as an example of the network signal 800 indicative of the reference time (e.g., SIB9), the network signal 800 may be generated at the CU and passed to the DU for the transmission 410. Optionally, the DU may overwrite and/or refresh and/or re-encode a field time (which may be indicative of the reference time) in the IE ReferenceTimeInfo-r16 before transmission 410 (over the radio interface). It is possible to overwrite because SIB9 is not encrypted by the CU. The reason to modify the field time is that the clock of the gNB 100 is located at the DU and there is an unknown and/or unexpected and/or varying delay between CU and DU. Even though CU can pre- compensate the delay between CU and DU when setting time in the CU message to DU, it may be inaccurate. It is preferable to allow DU to overwrite the field time (e.g., if possible). Alternatively or in addition, the DU may generate the network signal 800 (e.g., SIB9) on its own. For the RRC unicast message (e.g., as another example of the network signal 800) indicative of the reference time (i.e., DLInformationTransfer), the network signal 800 may generated at the CU, optionally encrypted. The CU may request the DU to deliver accurate information for the reference time either on demand or by a periodic reporting, e.g., as specified in the 3GPP document TS 38.473, version 16.8.0, clause 9.2.11. The degradation may be determined (e.g., according to any one of the steps 406, 408, 506, 508, and 601) first by the gNB 100, the UE 200, and/or the CN node 300, and (e.g., based on the first determination) signaled to at least one other of the gNB 100, the UE 200, and the CN node 300 (e.g., according to any one of the steps 408, 508, 601, and 608). In other words, the gNB 100, the UE 200, and/or the CN node 300 that determines the degradation first may initiate the delivery of the reference time, e.g., according to at least one of the following initiation alternatives. According to a first initiation alternative, the delivering is initiated by the core network (CN) 710, e.g., by the CN node 300 (e.g., the AF or the AMF). In one embodiment, the core network (CN) 710 discovered the need for 5G Time resilience (i.e., determines 601 the degradation) and requests 608 the NG-RAN node 100 to provide (i.e., to deliver, and particularly, to transmit) the 5G reference timing to the UE 200. In other words, the gNB 100 receives from the core network 710 (e.g., the CN node 300) a request (i.e., a CN request, e.g., the AF request) to provide time synchronization for one or more UEs 200. The gNB 100 can either accept this request or reject this request. In any embodiment, in the request, the CN 710 (i.e., the CN node 300) may indicate the required accuracy (e.g., a synchronization accuracy). Herein, whenever referring to the core network (CN) 710 may refer to the CN node 300 (e.g., the AF or the AMF). In any embodiment, the gNB 100 may reject the request, e.g., due to that 1. the current channel measurement from this gNB 100 to the UE 200 indicates a bad channel quality (e.g., the UE 200 is in the basement, or the UE 200 is a fast moving UE etc.), and/or 2. the UE is far away from the gNB (from the accumulated TA commands) and there is a need for propagation delay compensation. This bad channel quality or a need for propagation delay compensation (PDC), optionally combined with an overloaded radio resource, can lead to the determination (i.e., the selectivity in the step 410) that the gNB 100 may not be able to meet the required synchronization accuracy. In same or another embodiment, e.g. for the selectivity in the step 410, the gNB 100 keeps and/or continuously tracks an estimation of the current accuracy (i.e., accuracy level) of delivering the reference time. E.g., the accuracy may be calculated based on one of the below components: - In a first component, the UE 200 indicates the clock stratum level to the gNB 100. The clock stratum level may be, for example, a level 3 or a level 4 clock. The stratum level determines the stability of the UE clock (e.g., a drift) and subsequently influences the frequency of a refreshing and/or re- sending of the 5G reference time from the gNB 100 to the UE 200 on the Uu interface. A stratum level 4 clock means that the UE clock drifts more often than the stratum level 3 clock and so needs more frequent reference time delivery. - In a second component, the gNB 100 acquires a UE Rx-Tx measurement report (e.g., a report from the UE 200 that is indicative of a Rx-Tx difference) that is indicative of a quality and/or accuracy of the measurement. The quality of the measurement may be indicative of the accuracy level of the estimation of the propagation delay. Alternatively or in addition, the gNB 100 may read a gNB Rx-Tx measurement (e.g., a measurement from the gNB 100 or DU 100-DU that is indicative of a Rx-Tx difference). In the second component, the calculation may be based on the time when the propagation delay compensation is estimated and/or performed. - In a third component, the accuracy increases as the last time the UE 200 has been provided with the reference time from the gNB 100. The further away it is from the last update, the accuracy level deteriorates further. In any embodiment, the gNB 100 may accept the request received in the step 408 from the CN node 300 performing the step 608, if a synchronization error budget from the CN 710 is higher than the currently tracked accuracy, i.e., the gNB 100 is able provide the reference time to the UE 200 with an accuracy of the Uu interface that is better than what is required. Alternatively or in addition, the gNB 100 may reject, if a synchronization error budget from the core network is lower (e.g., allows for less time) than the currently tracked accuracy, i.e., the gNB 100 is not able to provide the reference time to the UE 200 with an accuracy of the Uu interface that is better than what is required. Any of the above embodiments may be used 1. when the gNB 100 has accepted the request and in anticipation of an updated error budget, and/or 2. when the gNB 100 is aware that the UE 200 has a subscription for a time resilience service (e.g., and this can be performed before a request from the core network 710). In another embodiment, a pro-active approach is used. The above approaches may be referred to as re-active. The gNB 100 may indicate to the CN 710 the best accuracy of the Uu interface that the gNB 100 is able to provide to the UE 200. For example, the gNB 100 may indicate 402 to the CN 710 that the gNB 100 may provide an accuracy (e.g., accuracy level) of the Uu interface equal to or less than 100 nanoseconds to one UE 200. In this or another embodiment, the gNB 100 may (e.g., in the step 402 or a further step 404), perform at least one of: 1. The gNB 100 may periodically report a best accuracy of the Uu interface with a periodicity configured by the CN 710. 2. The gNB 100 may report to the CN 710 when the best Uu interface accuracy becomes worse and/or better than a previously reported value. In a follow-up report 404, the gNB 100 may only report when an absolute difference between a current accuracy of the Uu interface and the previously reported value for the accuracy is larger than a (e.g., predefined) threshold, optionally wherein the threshold may either be fixed or configurable by the CN 710. 3. Upon receiving a time synchronization error budget (e.g., for the Uu interface), which may be the first time to receive the error budget or a later updated error budget), the gNB 100 may include additionally in the response to the request (i.e., a message indicative of accept or reject) in a step 410 the best Uu interface accuracy. a. For example, the gNB 100 receives 408 a request to provide an accuracy (e.g., an accuracy level) of the Uu interface equal to or less (i.e., better) than 200 nanoseconds. The gNB 100 may accept this request, and may additionally reply that the gNB 100 is able (i.e., capable) to achieve a best accuracy (i.e., accuracy level) of the Uu interface equal to or less than 100 nanoseconds. b. In another example, the gNB 100 receives a request to provide an accuracy (i.e., an accuracy level) of Uu interface that is equal to or less than 50 nanoseconds. The gNB 100 may reject this request, and may additionally reply that the gNB 100 is able to achieve a best accuracy (i.e., accuracy level) of Uu interface that is equal to or less than 100 nanoseconds. In this embodiment, once the CN 710 receives the best Uu interface budget that the gNB 100 is able to provide, the CN 710 does not wait for the gNB response (accept or reject) when the core network indicates to the gNB 100 the updated time synchronization error budget. Fig.10 schematically illustrates a signaling diagram (which may be equivalently interpreted as a flowchart) comprising example of the above steps in Alternative 1. Alternatively or in addition, any one of the CN node 300, the gNB 100, and/or the UE 200 may perform the steps for the Alternative 2 and/or 3, e.g., according to the list of embodiments and/or any one of below embodiments. In an embodiment (which may be combined with any other embodiment), after the gNB 100 rejects the request, the gNB 100 may perform some further actions so that a chance to meet the (e.g., synchronization) accuracy is estimated to be higher. These actions may include at least one of: 1. The gNB 100 may handover the UE 200 to another target, e.g., to a neighboring gNB 100) and/or in another radio band (e.g., from frequency range 2, FR2, to frequency range 1, FR1, or from FR1 to FR2). 2. The gNB 100 may change a Primary Cell (PCell) of the UE 200 (e.g., since the reference time is delivered from the PCell). For example, the gNB 100 may change the PCell of the UE 200 to one of the cells in control of (e.g., served by) the gNB 100. This cell may have more radio resources and/or this cell may have a better radio connection (i.e., channel quality) to the UE 200. 3. The gNB 100 may have obtained information of the neighboring gNB, e.g. using Artificial Intelligence (AI) and/or Machine Learning (ML), and thus may provide a better target (e.g., in a step of selecting the gNB 100) to fulfill one or more time resiliency requirements (e.g., the accuracy). According to a second initiation alternative, the delivering is initiated by the gNB 100. In same or another embodiment, if the gNB 100 detects 406 (e.g., determines 408 first) that the time source (e.g., the GNSS signal) is lost in its coverage area, then the gNB 100 may indicate so to the CN 710 or start to provide accurate 5G reference time (e.g., broadcast in SIB9) for at least one or all UEs 200 in a cell or a subset of UEs 200 which has subscribed to a timing resiliency service. In this embodiment, the accuracy (i.e., accuracy level) for the delivery of the reference time may be pre-configured to a particular value and/or included in a subscription information of the UE 200. In any embodiment, at least some or all steps of the method 600 may be performed by an Access and Mobility management Function (AMF) as an example of the CN node 300 in the CN 710. Alternatively or in addition, Fig.11 schematically illustrates a signaling diagram While the signaling diagrams in Fig.10 and 11 are described from the perspective of the gNB 100 for conciseness, corresponding steps of the UE 200 and/or the CN node 300 (e.g., the AF or the AMF) are disclosed as well by said description. According to a third initiation alternative, the delivering is initiated by the UE 200. In one embodiment, the UE 200 indicates on a radio resource control (RRC) layer to the gNB 100 that the UE 200 prefers to be provided with a reference time delivery due to the degradation (e.g., a loss) of the GNSS timing source (i.e., the GNSS signal) in the step 508. This preference (i.e., a RAN request to the RAN) may be added in a UE assistance information message. In one variant, the UE 200 may also explicitly indicate that it prefers (i.e., requests) to be provided with GNSS timing (i.e., the reference time) and also set the existing field referenceTimeInfoPreference to be true, e.g. while not providing a reason why GNSS timing is needed. In this embodiment, it is up-to the gNB 100 to decide whether to follow the preference of the UE 200. For example, the gNB 100 may check a subscription of the UE 200 to determine if the UE 200 is to be provided with GNSS timing in the step 410. The difference of this embodiment over another embodiment or a reference example can include that the request (e.g., a RAN request in the step 508) is from the UE 200 to the gNB 100, e.g. while the other embodiment or the reference example may require that the request (e.g., a NAS request in the step 508) is from the UE to the AF (application function) in an NAS message. A benefit of this embodiment can be that the request can be known at the gNB 100 earlier than the alternative. In any embodiment, the gNB 100 may prepare or perform an allocation of radio resources (e.g., reference signals for propagation delay compensation, PDC) and the generation of the network signal 800 and/or an accuracy reference timing RRC message. In 3GPP Release 16, the UE 200 may indicate that it prefers being provisioned with the timing information specified in the IE ReferenceTimeInfo. However, it is neither specified why the UE 200 prefers to be provided with reference time nor specified which types of clocks the UE 200 prefers. Any embodiment may be implemented using RRC signaling and/or an RRC layer. In one example, an information element (IE) comprising a field lossOfGNSS may be added in the UE assistance information message (as one example of the RAN request or RAN request message). The field lossOfGNSS may be defined as below:

Another example of implementation may add the below IE with a field gnss- Preference in the UE assistance information message (as one example of the RAN request or RAN request message) in the steps 508 and 408.

Any of the embodiments may be implemented according to, or by modifying, at least one of the 3GPP document TS 38.473, version 16.8.0; the 3GPP document TS 38.423, version 16.8.0; and the 3GPP document TS 38.331, 16.7.0. Alternatively or in addition, any of the embodiments may be implemented based on the Release 17 of New Radio Industrial Internet of Things (NR-IIoT). Alternatively or in addition, any embodiment may be based on 5G Timing Resiliency, e.g. according to the 3GPP document TS 22.261, version 18.4.0, or may use at least one of the following features. Radio communication systems using a radio access technology (RAT) or a core network (CN) technology of the fifth generation (5G) rely on reference precision timing signals for network synchronization in order to operate. These signals (also referred to as synchronization references) are generated by primary reference time clocks that typically get a timing reference from receivers of a Global Navigation Satellite System (GNSS). In order to meet the relevant synchronization requirements also during failure conditions, the synchronization network typically includes means to address a potential degradation of performance of the GNSS signal. Some deployments of 5G systems (5GSs) support applications sensitive to any degradation of the timing signal. In such cases, the 5G system is beneficially enhanced to act as a backup for loss of their GNSS references. The 5G system may act as a consumer of time synchronization and/or may benefit from timing resiliency which enables the support of many critical services within the 5G network 700 even during the event of a loss or degradation of the primary reference timing based on a GNSS. Additionally, for time critical services (e.g. financial sector or smart grid), the 5G system can operate in collaboration with or as backup to other timing solutions. A base of clock synchronization requirements when the 5G system is providing a time signal, if it is deployed in conjunction with an IEEE TSN network or if it is providing support for IEEE 1588 related protocols, is included in the 3GPP document TS 22.104, clause 5.6. The enhancements are to add timing resiliency to the 5G system enabling its use as a replacement (i.e., alternative) or backup for other timing sources. Any embodiment may implement at least some of the following features for timing resiliency. In general, the 5GS 700 may be able to maintain accurate time synchronization as appropriate for the supported applications in the event of degradation or loss of the primary timing reference (e.g., GNSS). Alternatively or in addition, any embodiment may monitor and/or report the GNSS signal. E.g., the 5GS 700 may be able to support mechanisms to monitor for timing source failure (e.g., GNSS). While the technique has been disclosed herein referring to the GNSS signal, any feature and aspect of the technique is also disclosed using a primary reference time signal (which replaces the GNSS signal). The reference time provided by means of the network signal may be a secondary reference time signal. The 5GS 700 may be able to detect (i.e., determine 601) when reference timing signals (e.g., from GNSS or other timing source) are no longer viable for network time synchronization. The 5GS 700 may support a mechanism to determine if there is degradation of the 5G time synchronization. Alternatively or in addition, the 5GS 700 may be able to support mechanisms to indicate to devices (e.g., UEs, applications) that there is an alternate time source available for use (e.g., a 5G system internal holdover capability, atomic clock, Synchronization over Fiber, a Terrestrial Beacon System (TBS), GNSS), taking into account the holdover capability of the devices. Alternatively or in addition, the 5GS 700 may be able to detect (e.g., determine 601) when a timing source fails or is restored for network time synchronization. Alternatively or in addition, the 5GS 700 may support mechanisms to monitor different time sources and adopt the most appropriate. Alternatively or in addition, the 5GS may support a mechanism to report timing errors, e.g., a divergence from Coordinated Universal Time (or universel temps coordonné, UTC) and time synchronization degradation to UEs 200 and 3rd party applications. Any embodiment of the technique may be indicated to any application (e.g., to the host computer), which is also referred to as Service Exposure. The 5GS may support a mechanism for a 3rd party application to request resilient timing with specific parameters (e.g. Key Performance Indicators (KPIs), e.g., accuracy, interval, coverage area. Any of the above embodiments may be implemented for 5G timing resiliency (according to 3GPP study document S2-2108474) and/or for 3GPP Release 18. In particular, any embodiment may be implemented to meet at least one of the following objectives: Support for 5G Timing Resiliency requirements — report 5G timing synchronization status to UEs and AFs - define how RAN and 5GC can learn about the timing synchronization status to inform the UE and/or an Application Function (AF). - determine if there is additional information to be provided to UE and/or AF as part of status. — define how to enable AF to request time synchronization service in a specific coverage area and how to enforce the coverage area — define how to control 5G time synchronization service based on subscription Fig.12 shows a schematic block diagram for an embodiment of the device 100. The device 100 comprises processing circuitry, e.g., one or more processors 1204 for performing the method 400 and memory 1206 coupled to the processors 1204. For example, the memory 1206 may be encoded with instructions that implement at least one of the modules 108 and 110. The one or more processors 1204 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 100, such as the memory 1206, network node functionality. For example, the one or more processors 1204 may execute instructions stored in the memory 1206. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 100 being configured to perform the action. As schematically illustrated in Fig.12, the device 100 may be embodied by a network node 1200, e.g., functioning as gNB or eNB or gNB-CU or gNB-DU. The network node 1200 comprises a (e.g., radio) interface 1202 coupled to the device 200 for (e.g., radio) communication with one or more radio devices and/or to the device 300 in the core network. Fig.13 shows a schematic block diagram for an embodiment of the device 200. The device 200 comprises processing circuitry, e.g., one or more processors 1304 for performing the method 500 and memory 1306 coupled to the processors 1304. For example, the memory 1306 may be encoded with instructions that implement at least one of the modules 208 and 210. The one or more processors 1304 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 200, such as the memory 1306, radio device functionality. For example, the one or more processors 1304 may execute instructions stored in the memory 1306. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 200 being configured to perform the action. As schematically illustrated in Fig.13, the device 200 may be embodied by a radio device 1300, e.g., functioning as UE. The radio device 1300 comprises a radio interface 1302 coupled to the device 100 for (e.g., radio) communication with a network node and/or CN. Fig.14 shows a schematic block diagram for an embodiment of the device 300. The device 300 comprises processing circuitry, e.g., one or more processors 1404 for performing the method 600 and memory 1406 coupled to the processors 1404. For example, the memory 1406 may be encoded with instructions that implement at least one of the modules 301 and 308. The one or more processors 1404 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 300, such as the memory 1406, radio device functionality. For example, the one or more processors 1404 may execute instructions stored in the memory 1406. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 300 being configured to perform the action. As schematically illustrated in Fig.14, the device 300 may be embodied by a CN or CN node 1400, e.g., functioning as a AF or AMF. The CN or CN node 1400 comprises an interface 1602 coupled to the device 100 for communication with one or more network nodes and/or a UEs. With reference to Fig.15, in accordance with an embodiment, a communication system 1500 includes a telecommunication network 1510, such as a 3GPP-type cellular network, which comprises an access network 1511, such as a radio access network, and a core network 1514. The access network 1511 comprises a plurality of base stations 1512a, 1512b, 1512c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1513a, 1513b, 1513c. Each base station 1512a, 1512b, 1512c is connectable to the core network 1514 over a wired or wireless connection 1515. A first user equipment (UE) 1591 located in coverage area 1513c is configured to wirelessly connect to, or be paged by, the corresponding base station 1512c. A second UE 1592 in coverage area 1513a is wirelessly connectable to the corresponding base station 1512a. While a plurality of UEs 1591, 1592 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 1512. Any of the base stations 1512 and the UEs 1591, 1592 may embody the device 100 or 1200 and the device 200 and 1300, respectively. The telecommunication network 1510 is itself connected to a host computer 1530, 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 1530 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 1521, 1522 between the telecommunication network 1510 and the host computer 1530 may extend directly from the core network 1514 to the host computer 1530 or may go via an optional intermediate network 1520. The intermediate network 1520 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1520, if any, may be a backbone network or the Internet; in particular, the intermediate network 1520 may comprise two or more sub-networks (not shown). The communication system 1500 of Fig.15 as a whole enables connectivity between one of the connected UEs 1591, 1592 and the host computer 1530. The connectivity may be described as an over-the-top (OTT) connection 1550. The host computer 1530 and the connected UEs 1591, 1592 are configured to communicate data and/or signaling via the OTT connection 1550, using the access network 1511, the core network 1514, any intermediate network 1520 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1550 may be transparent in the sense that the participating communication devices through which the OTT connection 1550 passes are unaware of routing of uplink and downlink communications. For example, a base station 1512 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1530 to be forwarded (e.g., handed over) to a connected UE 1591. Similarly, the base station 1512 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1591 towards the host computer 1530. By virtue of the method 200 being performed by any one of the UEs 1591 or 1592 and/or any one of the base stations 1512, the performance or range of the OTT connection 1550 can be improved, e.g., in terms of increased throughput and/or reduced latency. More specifically, the host computer 1530 may indicate to the RAN 720 or the radio device 200 or the network node 100 (e.g., on an application layer) the QoS of the traffic or any other of the above-mentioned KPIs. 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 Fig.16. In a communication system 1600, a host computer 1610 comprises hardware 1615 including a communication interface 1616 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1600. The host computer 1610 further comprises processing circuitry 1618, which may have storage and/or processing capabilities. In particular, the processing circuitry 1618 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 1610 further comprises software 1611, which is stored in or accessible by the host computer 1610 and executable by the processing circuitry 1618. The software 1611 includes a host application 1612. The host application 1612 may be operable to provide a service to a remote user, such as a UE 1630 connecting via an OTT connection 1650 terminating at the UE 1630 and the host computer 1610. In providing the service to the remote user, the host application 1612 may provide user data, which is transmitted using the OTT connection 1650. The user data may depend on the location of the UE 1630. The user data may comprise auxiliary information or precision advertisements (also: ads) delivered to the UE 1630. The location may be reported by the UE 1630 to the host computer, e.g., using the OTT connection 1650, and/or by the base station 1620, e.g., using a connection 1660. The communication system 1600 further includes a base station 1620 provided in a telecommunication system and comprising hardware 1625 enabling it to communicate with the host computer 1610 and with the UE 1630. The hardware 1625 may include a communication interface 1626 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1600, as well as a radio interface 1627 for setting up and maintaining at least a wireless connection 1670 with a UE 1630 located in a coverage area (not shown in Fig.16) served by the base station 1620. The communication interface 1626 may be configured to facilitate a connection 1660 to the host computer 1610. The connection 1660 may be direct, or it may pass through a core network (not shown in Fig.16) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1625 of the base station 1620 further includes processing circuitry 1628, 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 1620 further has software 1621 stored internally or accessible via an external connection. The communication system 1600 further includes the UE 1630 already referred to. Its hardware 1635 may include a radio interface 1637 configured to set up and maintain a wireless connection 1670 with a base station serving a coverage area in which the UE 1630 is currently located. The hardware 1635 of the UE 1630 further includes processing circuitry 1638, 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 1630 further comprises software 1631, which is stored in or accessible by the UE 1630 and executable by the processing circuitry 1638. The software 1631 includes a client application 1632. The client application 1632 may be operable to provide a service to a human or non-human user via the UE 1630, with the support of the host computer 1610. In the host computer 1610, an executing host application 1612 may communicate with the executing client application 1632 via the OTT connection 1650 terminating at the UE 1630 and the host computer 1610. In providing the service to the user, the client application 1632 may receive request data from the host application 1612 and provide user data in response to the request data. The OTT connection 1650 may transfer both the request data and the user data. The client application 1632 may interact with the user to generate the user data that it provides. It is noted that the host computer 1610, base station 1620 and UE 1630 illustrated in Fig.16 may be identical to the host computer 1530, one of the base stations 1512a, 1512b, 1512c and one of the UEs 1591, 1592 of Fig.15, respectively. This is to say, the inner workings of these entities may be as shown in Fig.16, and, independently, the surrounding network topology may be that of Fig.15. In Fig.16, the OTT connection 1650 has been drawn abstractly to illustrate the communication between the host computer 1610 and the UE 1630 via the base station 1620, 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 1630 or from the service provider operating the host computer 1610, or both. While the OTT connection 1650 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). The wireless connection 1670 between the UE 1630 and the base station 1620 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 1630 using the OTT connection 1650, in which the wireless connection 1670 forms the last segment. More precisely, the teachings of these embodiments may reduce the latency and improve the data rate and thereby provide benefits such as better responsiveness and improved QoS. A measurement procedure may be provided for the purpose of monitoring data rate, latency, QoS and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1650 between the host computer 1610 and UE 1630, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1650 may be implemented in the software 1611 of the host computer 1610 or in the software 1631 of the UE 1630, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1650 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 1611, 1631 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1620, and it may be unknown or imperceptible to the base station 1620. 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 1610 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 1611, 1631 causes messages to be transmitted, in particular empty or "dummy" messages, using the OTT connection 1650 while it monitors propagation times, errors etc. Fig.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.15 and 16. For simplicity of the present disclosure, only drawing references to Fig.17 will be included in this paragraph. In a first step 1710 of the method, the host computer provides user data. In an optional substep 1711 of the first step 1710, the host computer provides the user data by executing a host application. In a second step 1720, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1730, 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 1740, the UE executes a client application associated with the host application executed by the host computer. Fig.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.15 and 16. For simplicity of the present disclosure, only drawing references to Fig.18 will be included in this paragraph. In a first step 1810 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 1820, 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 1830, the UE receives the user data carried in the transmission. As has become apparent from above description, at least some embodiments of the technique ensure that the radio device (e.g., UE) can be provided with an alternative GNSS time from the network node (e.g., gNB), e.g. with a guaranteed delivery accuracy. Many advantages of the present invention will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the units and devices without departing from the scope of the invention and/or without sacrificing all of its advantages. Since the invention can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the following claims.

Claims

Claims 1. A method (400) performed by a network node (100; 1200; 1512; 1620) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the method (400) comprising or initiating: determining (408) a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining (408) of the degradation, selectively transmitting (410) a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

2. The method (400) of claim 1, wherein the network signal (800) indicative of the reference time and/or a request message indicative of the degradation from the radio device (200) received for the determining (408) comprises at least one of: a radio resource control, RRC, signal, optionally comprising a reference time information element that is indicative of the reference time; and an assistance information, AI.

3. The method (400) of claim 1 or 2, further comprising or initiating: receiving (406) a signal of a GNSS (1100) at the network node (100; 1200; 1512; 1620), wherein the network signal (800) is derived from the signal of the GNSS (1100) at the network node (100; 1200; 1512; 1620).

4. The method (400) of any one of claims 1 to 3, wherein the selectivity of the transmission (410) depends on a result of a comparison between a required accuracy of the delivery of the reference time to the radio device (200; 1300; 1591; 1592; 1630) and an achievable accuracy of the delivery of the reference time to the radio device (200; 1300; 1591; 1592; 1630).

5. The method (400) of any one of claims 1 to 4, further comprising or initiating at least one of: sending (402) an accuracy report from the network node (100; 1200; 1512; 1620) to a core network, CN, the accuracy report being indicative of an or the achievable accuracy of the delivery of the reference time; and sending (404) a candidate message from the network node (100; 1200; 1512; 1620) to a or the CN, the candidate message being indicative of one or more candidate network nodes (100-cand) for delivering the reference time with a or the required accuracy.

6. The method (400) of any one of claims 1 to 5, wherein the network node (100; 1200; 1512; 1620) comprises a GNSS receiver for receiving (406) a GNSS signal from a or the GNSS (1100) at the network node (100; 1200; 1512; 1620) and/or deriving the network signal (800) that is indicative of the reference time, optionally wherein the degradation of the GNSS signal is determined (408) using the GNSS receiver at the network node (100; 1200; 1512; 1620).

7. The method (400) of any one of claims 1 to 6, wherein the determining (408) of the degradation of the GNSS signal comprises receiving a request message from the radio device (200; 1300; 1591; 1592; 1630), the request message being indicative of the degradation of the GNSS signal at the radio device (200; 1300; 1591; 1592; 1630); and wherein the network signal (800) is selectively transmitted (410) to the radio device (200; 1300; 1591; 1592; 1630) responsive to the request message.

8. The method (400) of any one of claims 1 to 7, wherein the determining (408) of the degradation of the GNSS signal comprises receiving a control message from a or the CN, the control message being indicative of the degradation of the GNSS signal at the radio device (200; 1300; 1591; 1592; 1630); and wherein the network signal (800) is selectively transmitted (410) to the radio device (200; 1300; 1591; 1592; 1630) responsive to the control message.

9. The method (400) of claim 8, wherein the control message received (408) from the CN is indicative of the reference time, optionally wherein the control message is received (408) from the CN responsive to a degradation report that is indicative of the degradation of the GNSS signal in a geographical area of the network node (100; 1200; 1512; 1620).

10. The method (400) of any one of claims 1 to 9, wherein the selectively transmitting (410) further comprises: sending a response to the core network (300), the response being indicative of whether or not the network node (100; 1200; 1512; 1620) transmits the network signal (800) indicative of the reference time to the radio device (200; 1300; 1591; 1592; 1630).

11. A method (500) performed by a radio device (200; 1300; 1591; 1592; 1630) for receiving a reference time from a network node (100; 1200; 1512; 1620), the method (500) comprising or initiating: determining (508) a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and upon the determining (508) of the degradation, receiving (510) a network signal (800) from the network node (100; 1200; 1512; 1620), the network signal (800) being indicative of the reference time.

12. The method (500) of claim 11, wherein the determining (508) of the degradation of the GNSS signal comprises transmitting a request message from the radio device (200; 1300; 1591; 1592; 1630) to at least one of the network node (100; 1200; 1512; 1620) and the core network (300), the request message being indicative of the determined (508) degradation of the GNSS signal at the radio device (200; 1300; 1591; 1592; 1630); and wherein the network signal (800) is received (510) responsive to the request message.

13. The method (500) of claim 11 or 12, wherein the radio device (200; 1300; 1591; 1592; 1630) comprises a GNSS receiver for receiving (506) a GNSS signal from the GNSS (1100) at the radio device (200; 1300; 1591; 1592; 1630) and/or deriving the reference time, optionally wherein the degradation of the GNSS signal is determined (408) using the GNSS receiver at the radio device (200; 1300; 1591; 1592; 1630).

14. The method (500) of any one of claims 11 to 13, further comprising features or steps of any one of claims 2 to 10 or the features or steps corresponding thereto.

15. A method (600) performed by a core network (300) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the method (600) comprising or initiating: determining (601) a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining (601) of the degradation, requesting (608) a network node (100; 1200; 1512; 1620) to transmit a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

16. The method (600) of claim 15, further comprising or initiating: selecting the network node (100; 1200; 1512; 1620) or another candidate network node (100-cand) to be requested (608) to transmit the network signal (800) to the radio device (200; 1300; 1591; 1592; 1630).

17. The method (600) of claim 15 or 16, further comprising at least one of: receiving (602) an accuracy report from at least one or each of the network node (100; 1200; 1512; 1620) and another or the other candidate network node (100-cand), the accuracy report being indicative of an achievable accuracy of the delivery of the reference time using the respective network node (100; 100-cand); and receiving (604) a candidate message from the network node (100; 1200; 1512; 1620), the candidate message being indicative of one or more candidate network nodes (100-cand) for delivering the reference time with a required accuracy.

18. The method (600) of claim 16 and 17, wherein the network node (100; 1200; 1512; 1620) or the other candidate network node (100-cand) is selected among the indicated one or more candidate network nodes and/or based on comparing the accuracy reports.

19. The method (600) of any one of claims 15 to 18, further comprises: receiving (610) a response from the network node (100; 1200; 1512; 1620) to the requesting (610), the response being indicative of whether or not the network node (100; 1200; 1512; 1620) transmits the network signal (800) indicative of the reference time to the radio device (200; 1300; 1591; 1592; 1630).

20. The method (600) of any one of claims 15 to 19, further comprising features or steps of any one of claims 2 to 10 or 12 to 14, or the features or steps corresponding thereto.

21. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 10, 11 to 14 or 15 to 20 when the computer program product is executed on one or more computing devices (1204; 1306; 1404), optionally stored on a computer-readable recording medium (1206; 1306; 1406).

22. A network node (100; 1200; 1512; 1620) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the network node (100; 1200; 1512; 1620) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node (100; 1200; 1512; 1620) is operable to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, selectively transmit a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

23. The network node (100; 1200; 1512; 1620) of claim 22, further operable to perform any one of the steps of any one of claims 2 to 10.

24. A network node (100; 1200; 1512; 1620) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the network node (100; 1200; 1512; 1620) being configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, selectively transmit a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

25. The network node (100; 1200; 1512; 1620) of claim 24, further configured to perform any one of the steps of any one of claims 2 to 10.

26. A base station (100; 1200; 1512; 1620) for delivering a reference time to a UE (200; 1300; 1591; 1592; 1630), the base station (100; 1200; 1512; 1620) being configured to communicate with the UE (200; 1300; 1591; 1592; 1630), the base station (100; 1400; 1512; 1620) comprising a radio interface (1202; 1627) and processing circuitry (1204; 1628) configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the UE (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, selectively transmit a network signal (800) to the UE (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

27. The base station (100; 1200; 1512; 1620) of claim 26, wherein the processing circuitry (1204; 1628) is further configured to execute the steps of any one of claims 2 to 10.

28. A radio device (200; 1300; 1591; 1592; 1630) for receiving a reference time from a network node (100; 1200; 1512; 1620), the radio device (200; 1300; 1591; 1592; 1630) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the radio device (200; 1300; 1591; 1592; 1630) is operable to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and upon the determining of the degradation, receive a network signal (800) from the network node (100; 1200; 1512; 1620), the network signal (800) being indicative of the reference time.

29. The radio device (200; 1300; 1591; 1592; 1630) of claim 28, further operable to perform the steps of any one of claims 12 to 14.

30. A radio device (200; 1300; 1591; 1592; 1630) for receiving a reference time from a network node (100; 1200; 1512; 1620), the radio device (200; 1300; 1591; 1592; 1630) being configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and upon the determining of the degradation, receive a network signal (800) from the network node (100; 1200; 1512; 1620), the network signal (800) being indicative of the reference time.

31. The radio device (200; 1300; 1591; 1592; 1630) of claim 30, further configured to perform the steps of any one of claims 12 to 14.

32. A user equipment, UE (200; 1300; 1591; 1592; 1630) for receiving a reference time from a network node (100; 1200; 1512; 1620), the UE (200; 1300; 1591; 1592; 1630) being configured to communicate with a base station (100; 1200; 1512; 1620) or with a radio device functioning as a gateway, the UE (200; 1300; 1591; 1592; 1630) comprising a radio interface (1302; 1637) and processing circuitry (1304; 1638) configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the UE (200; 1300; 1591; 1592; 1630); and upon the determining of the degradation, receive a network signal (800) from the base station (100; 1200; 1512; 1620), the network signal (800) being indicative of the reference time.

33. The UE (200; 1300; 1591; 1592; 1630) of claim 32, wherein the processing circuitry (1304; 1638) is further configured to execute the steps of any one of claims 12 to 14.

34. A core network, CN, or CN node (300; 710; 1400; 1510) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the CN or CN node (300; 710; 1400; 1510) comprising memory (1406) operable to store instructions and processing circuitry (1404) operable to execute the instructions, such that the CN or CN node (300; 710; 1400; 1510) is operable to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, request a network node (100; 1200; 1512; 1620) to transmit a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

35. The CN or CN node (300; 710; 1400; 1510) of claim 34, further operable to perform any one of the steps of any one of claims 16 to 20.

36. A core network, CN, or CN node (300; 710; 1400; 1510) for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the CN or CN node (300; 710; 1400; 1510) being configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, request a network node (100; 1200; 1512; 1620) to transmit a network signal (800) to the radio device (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

37. The CN or CN node (300; 710; 1400; 1510) of claim 36, further configured to perform any one of the steps of any one of claims 16 to 20.

38. An application function, AF (300; 710; 1400; 1510), for delivering a reference time to a radio device (200; 1300; 1591; 1592; 1630), the AF (300; 710; 1400; 1510) being configured to communicate with a user equipment, UE (200; 1300; 1591; 1592; 1630), through a base station (100; 1400; 1512; 1620), the AF (300; 710; 1400; 1510) comprising a network interface (1402) and processing circuitry (1404) configured to: determine a degradation of a Global Navigation Satellite System, GNSS, signal indicative of the reference time at the radio device (200; 1300; 1591; 1592; 1630); and responsive to the determining of the degradation, request the base station (100; 1200; 1512; 1620) to transmit a network signal (800) to the UE (200; 1300; 1591; 1592; 1630), the network signal (800) being indicative of the reference time.

39. The AF (300; 710; 1400; 1510) of claim 38, wherein the processing circuitry (1404) is further configured to execute the steps of any one of claims 16 to 20.

40. A communication system (1500; 1600) including a host computer (1530; 1610) comprising: processing circuitry (1618) configured to provide user data; and a communication interface (1616) configured to forward user data to a cellular or ad hoc radio network (1510) for transmission to a user equipment, UE (200; 1300; 1591; 1592; 1630), wherein the UE (200; 1300; 1591; 1592; 1630) comprises a radio interface (1302; 1637) and processing circuitry (1304; 1638), the processing circuitry (1304; 1638) of the UE (200; 1300; 1591; 1592; 1630) being configured to execute the steps of any one of claims 1 to 20.

41. The communication system (1500; 1600) of claim 40, further including the UE (200; 1300; 1591; 1592; 1630).

42. The communication system (1500; 1600) of claim 40 or 41, wherein the radio network (1510) further comprises a base station (100; 1200; 1512; 1620), or a radio device (200; 1300; 1591; 1592; 1630) functioning as a gateway, which is configured to communicate with the UE (200; 1300; 1591; 1592; 1630).

43. The communication system (1500; 1600) of claim 42, wherein the base station (100; 1200; 1512; 1620), or the radio device (200; 1300; 1591; 1592; 1630) functioning as a gateway, comprises processing circuitry (1204; 1628), which is configured to execute the steps of claim 1 to 20.

44. The communication system (1500; 1600) of any one of claims 40 to 43, wherein: the processing circuitry (1618) of the host computer (1530; 1610) is configured to execute a host application (1612), thereby providing the user data; and the processing circuitry (1304; 1638) of the UE (200; 1300; 1591; 1592; 1630) is configured to execute a client application (1632) associated with the host application (1612).