WO2022084483A1

WO2022084483A1 - Technique for handling a survival time in a time-sensitive communication

Info

Publication number: WO2022084483A1
Application number: PCT/EP2021/079291
Authority: WO
Inventors: Zhenhua Zou; John Walter Diachina; Torsten DUDDA; Marilet DE ANDRADE JARDIM
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-10-22
Filing date: 2021-10-21
Publication date: 2022-04-28

Abstract

A technique for handling a survival time, ST, for data traffic of a time-sensitive communication, TSC, transmitted from a network node of a radio access network, RAN, to a radio device is described. As to a method aspect of the technique, traffic information of the TSC is received. The traffic information is indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node within a packet delay budget, PDB, of the RAN to the radio device. The method further comprises, responsive to a failure of the transmission within the PDB, initiating (404A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET, and/or responsive to a success of the transmission within the PDB, initiating or reinitiating (404B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

Description

TECHNIQUE FOR HANDLING A SURVIVAL TIME IN A TIME-SENSITIVE COMMUNICATION

Technical Field

The present disclosure relates to a technique for handling a survival time in a time-sensitive communication. More specifically, and without limitation, methods and devices are provided for handling a survival time (ST) for data traffic of a timesensitive communication (TSC) transmitted from a network node (200) of a radio access network (RAN) to a radio device or vice versa.

Background

The Third Generation Partnership Project (3GPP) defined survival time (ST), e.g., according to the 3GPP document TS 22.104, version 17.4.0, as the time that an application consuming a communication service may continue without an anticipated message.

As such, there is the challenge of how to map this application layer definition of the ST to, e.g., a medium access control (MAC) layer operation, in which a transmitting MAC entity receives one or more packets within a time period spanned by a beginning and an end of a burst, and has a limited time available for assembling and transmitting a MAC packet data unit (PDU).

In the study on "enhanced support of Industrial Internet of Things (I loT) in the 5G System (5GS)" in SA2 of 3GPP, one key issue is on the use of the ST for deterministic application in the fifth generation system (5GS).

The packets (or frames) can arrive at any time between the beginning and the end of the burst. However, existing techniques fail to define how the ST is measured in relation to a Quality of Service (QoS) framework or TSC assistance information (TSCAI) and at which time an anticipated message is declared as "not received".

Assuming that there is one application-layer message per burst, potentially segmented into multiple packets, and the measuring of the ST related to the bursts by indicating the ST in the TSCAI can lead to inconsistencies in the definition or computation of the SL. For example, when a first data packet arrives early within a first burst and a second packet arrives late in a second burst, the time difference between the transmissions of these packets may exceed the ST, even though each transmission is within the allowed packet delay budget (PDB).

Summary

Accordingly, there is a need for a technique that handles the survival time consistently relative to the beginning of a burst or the end of a burst and takes into account the packet delay budget of a time-sensitive communication (e.g., of a corresponding QoS flow).

As to a first method aspect, a method of handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a network node of a radio access network (RAN) to a radio device is provided. The method comprises or initiates a step of receiving traffic information of the TSC. The traffic information is indicative of a burst arrival time (BAT) and a burst end time (BET). One or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node within a packet delay budget (PDB) of the RAN to the radio device. The method further comprises or initiates at least one of: a step of initiating an ST timer for the ST responsive to a failure of the transmission within the PDB, wherein the ST is counted as starting from the PDB measured after the BET; and a step of initiating or reinitiating the ST timer for the ST responsive to a success of the transmission within the PDB, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

The first method and device aspects may be implemented or embodied by the network node.

The failure of the transmission of the one or more data packets may also be referred to as the one or more data packets being not delivered upon expiry of the PDB or within the PDB.

Initiating the ST timer may comprise starting or restarting the ST timer for the ST. The traffic information may be defined in accordance with or as an extension of Table 5.27.2-1 in the 3GPP document TS 23.501, version 16.6.0.

The initiating of the ST timer (e.g., according to the first method aspect) may be triggered upon expiry of the PDB as measured after the BET.

The ST timer (e.g., according to the first method aspect) may be initiated if the transmission fails within the PDB as measured after the BET.

The ST (e.g., according to the first method aspect) may be independent of a time of arrival of the one or more data packets between the BAT and the BET.

The one or more data packets (e.g., according to the first method aspect) may arrive at the network node between the BAT and the BET.

The one or more data packets (e.g., according to the first method aspect) may be transmitted by the network node within the PDB of the RAN measured after the arrival of the respective one of the one or more data packets or within the PDB measured after the arrival of the last one of the one or more data packets.

The data traffic (e.g., according to the first method aspect) may comprise a plurality of periodic bursts. The BAT and the BET may be indicative of the burst arrival time and the burst end time of a first burst of the periodic bursts.

The method may further comprises transmitting one or more further data packets of the data traffic that arrived in a second burst of the periodic bursts after the first burst. The one or more further data packets may be transmitted by the network node within the PDB of the RAN to the radio device.

Each of the bursts may comprise a set of the one or more data packets to be aggregated in the transmission of the RAN (e.g., by the network node) subsequent to the BET of the respective burst. The bursts may be a data bursts.

The second burst (e.g., according to the first method aspect) may be subsequent to the first burst in the plurality of periodic bursts. The one or more further data packets (e.g., according to the first method aspect), which are transmitted in the PDB after the second burst, may be declared and/or counted as a successful transmission.

The one or more further data packets (e.g., according to the first method aspect), which are transmitted in the PDB after the second burst, may be transmitted at the network node and/or received at the radio device prior to expiry of the ST timer.

The ST (e.g., according to the first method aspect) may be equal to, or may be an integer multiple of, a periodicity of the periodic bursts in the TSC.

The one or more data packets (e.g., according to the first method aspect) may belong to a Quality of Service (QoS) flow of the TSC. The QoS flow may be associated with the PDB.

The Packet Delay Budget (PDB) may define an upper bound for the time that a packet may be delayed between the UE and the N6 termination point at the UPF. For a certain 5G QoS Identifier (5QI), the value of the PDB may be the same in UL and DL. In the case of 3GPP access, the PDB may be used to support the configuration of scheduling and link layer functions (e.g., the setting of scheduling priority weights and HARQ target operating points). For GBR QoS Flows using the Delay-critical resource type, a packet delayed more than PDB may be counted as lost if the data burst is not exceeding a Maximum Data Burst Volume (MDBV) within the period of PDB and the QoS Flow is not exceeding a Guaranteed Flow Bit Rate (GFBR). For GBR QoS Flows with a Guaranteed Bit Rate (GBR) resource type not exceeding GFBR, 98 percent of the packets shall not experience a delay exceeding the SQI's PDB.

The 5G Access Network Packet Delay Budget (5G-AN PDB) may be determined by subtracting a static value for the Core Network Packet Delay Budget (CN PDB), which represents the delay between any N6 termination point at the UPF (for any UPF that may possibly be selected for the PDU Session) and the 5G-AN from a given PDB.

The packets may be frames of the TSC. Herein, N6 may refer to an interface between a Data Network (DN) and the UPF.

The BAT (e.g., according to the first method aspect) may be the latest possible time of arrival of a first data packet of the one or more data packets at the RAN or at the network node, optionally at a time sensitive networking ingress of the RAN or of the network node.

The BET (e.g., according to the first method aspect) may be the latest possible time of arrival of a last data packet of the one or more data packets at the RAN or at the network node, optionally at a time sensitive networking ingress of the RAN or of the network node.

The one or more data packets (e.g., according to the first method aspect) for which the transmission failed within the PDB may be declared and/or counted as lost or failed.

The one or more data packets (e.g., according to the first method aspect) may belong to single message of the TSC.

A message in the TSC may be segmented into the data packets.

The message (e.g., according to the first method aspect) may be declared and/or counted as lost or failed, if the transmission of at one of the data packets failed within the PDB.

The traffic information message (e.g., according to the first method aspect) may be further indicative of the ST.

The ST (e.g., according to the first method aspect) may be counted as starting from the BET plus the duration of the PDB.

The traffic information (e.g., according to the first method aspect) may be or comprise a TSC assistance information (TSCAI).

At least one of the ST and the BET may be received in and/or derived from the TSCAI. The TSCAI (e.g., according to the first method aspect) may be indicative of at least one of a flow direction of the TSC, a periodicity of bursts in the TSC, the BAT, and the BET.

The method (e.g., according to the first method aspect), wherein a flow direction of the TSC is downlink.

The traffic of the TSC may also be referred to as a TSC flow.

The transmission or an attempt of the failed transmission of the one or more data packets (e.g., according to the first method aspect) may comprise assembling the one or more data packets in a medium access control (MAC) packet data unit (PDU) for the transmission or the attempt of the failed transmission.

For example, the network node may assemble or attempt to assemble all data packets of the message that are received within the first burst in a MAC PDU.

The transmission of the one or more further data packets (e.g., according to the first method aspect) may comprise assembling the one or more further data packets in a medium access control (MAC) packet data unit (PDU) for the transmission.

For example, the network node may assemble all further data packets of the message that are received within the second burst in a MAC PDU for the transmission.

The survival time (ST) (e.g., according to the first method aspect) may be measured and/or computed relative to the BET plus the duration of the PDB.

The ST timer (e.g., according to the first method aspect) may be initiated at expiry of the PDB as measured from the BET.

For example, the ST timer for the ST is initiated at BET+PDB.

The PDB (e.g., according to the first method aspect) may be a maximum delay of the traffic in the RAN. The PDB (e.g., according to the first method aspect) may be defined for each data packet within a QoS flow.

The RAN may also be referred to an access network. The PDB may be referred to as an access network PDB, e.g., a 5G-AN PDB.

Alternatively or in addition, the RAN or the network node (e.g., according to the first method aspect), may schedule the radio device for the data traffic of the TSC based on at least one of the traffic information and the TSCAI.

Alternatively or in addition, the RAN or the network node (e.g., according to the first method aspect) may schedule the radio device for the data traffic of the TSC using at least one of semi-persistent scheduling (SPS), dynamic assignments, configured grants (CG), and dynamic grants.

The ST (e.g., according to the first method aspect) may be at least one of computed and received for a Quality of Service (QoS) flow of the TSC.

The TSC (e.g., according to the first method aspect) may be integrated transparently as a bridge in a time-sensitive networking (TSN) network.

The time-sensitive networking (TSN) network, e.g., according to IEEE 802.1, may also be referred to as a time-sensitive network or TSN.

The TSCAI may be defined in accordance with Table 5.27.2-1 in the 3GPP document TS 23.501, version 16.6.0.

The at least one of the traffic information and the TSCAI (e.g., according to the first method aspect) may be indicative of traffic patterns of the data traffic of the TSC at a TSN ingress of the RAN (e.g., at a TSN ingress of the network node) for the data traffic in downlink direction.

The network node may be a fifth or next generation node B (gNodeB or gNB). The RAN may be fifth generation access network (5G-AN). The at least one of the traffic information and the TSCAI (e.g., according to the first method aspect) may be associated with at least one of a data packet unit (PDU) session of the TSC and a Quality of Service (QoS) flow of the TSC.

The TSCAI may be based on Per-Stream Filtering and Policing (PSFP) information. Alternatively or in addition, the PSFP information may be provided by a Centralized Network Configuration (CNC) of the TSN.

The at least one of the traffic information and the TSCAI (e.g., according to the first method aspect) may be received from a Session Management Function (SMF) at the RAN and/or at the network node, optionally upon setup or establishment of the QoS Flow for the radio device.

The SMF may derive the TSCAI on a per QoS Flow basis. The SMF may sends the TSCAI to the RAN (e.g., the 5G-AN). The TSCAI may be indicative of the BAT of the bursts and/or a periodicity of the bursts. The BAT and/or the periodicity may be specified with respect to a clock of the RAN or a network system (e.g., 5G system or 5GS) comprising the RAN, e.g., a 5G clock.

The success or failure of the transmission of any one of the one or more data packets (e.g., according to the first method aspect) may be determined by an extended PDB as measured from the time of arrival of the respective packet. The extended PDB may include the time remaining between the time of arrival of the respective packet and the BET.

The success or failure of the transmission of any one of the one or more data packets (e.g., according to the first method aspect) may be determined by a reduced PDB as measured from the time of arrival of the respective packet. The reduced PDB may be reduced by the time difference between the BAT and the BET.

Herein, "measured from" may mean "measured relative to".

The network node may transmit at least one of the one or more data packets or the one or more further data packets after the PDB measured from the time of arrival of the respective packet. The at least one data packet transmitted after the PDB measured from the time of arrival of the respective packet (e.g., according to the first method aspect) may be declared and/or counted as a successful transmission, if the at least one data packet is transmitted by the network node and/or received by the radio device within the ST and/or within the PDB measured from the BET.

The ST timer (e.g., according to the first method aspect) may be associated with the data packet, the transmission of which failed. Alternatively or in addition, the ST timer may be associated with the message the transmission of which failed.

The at least one of the ST timer and the ST (e.g., according to the first method aspect) may be implemented as a MAC layer of the network node.

The success or failure of the transmission of the one or more data packets (e.g., according to the first method aspect) may depend on whether one MAC PDU assembled to comprise the one or more data packets is transmitted within the PDB, optionally measured from the BET.

The at least one of the ST timer and the ST (e.g., according to the first method aspect) may be implemented as a packet data convergence protocol (PDCP) layer of the network node.

The success or failure of the transmission of the one or more data packets (e.g., according to the first method aspect) may depend on whether one or more MAC PDUs comprising the one or more data packets are transmitted within the PDB, optionally measured from the BET.

The failure of the transmission of the one or more data packets (e.g., according to the first method aspect) may be determined using a PDCP discard timer of the PDCP layer.

The failure or the failure of the transmission within the PDB (e.g., according to the first method aspect) may be triggered by at least one of the followings:

- not receiving a positive hybrid automatic repeat request (HARQ) feedback within the PDB;

- receiving no HARQ feedback or a negative HARQ feedback, optionally and not being able to retransmit a HARQ transport block within the PDB; - not receiving a positive radio link control (RLC) status report feedback within the PDB;

- receiving no or negative RLC status report feedback, optionally and not being able to retransmit an RLC PDU within the PDB; and

- not attempting to transmit the one or more data packets within the PDB, optionally due to queueing or discarding of the one or more data packets.

The ST (e.g., according to the first method aspect) may be defined in units of time, optionally corresponding to the periodicity of the periodic bursts.

The ST (e.g., according to the first method aspect) may be defined as the maximum number of consecutive failures of the transmission of the data packets or the message.

As to a second method aspect a method of handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a radio device to a network node of a radio access network (RAN) is provided. The method comprises or initiates a step of receiving traffic information of the TSC. The traffic information is indicative of a burst arrival time (BAT) and a burst end time (BET). One or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the radio device within a packet delay budget (PDB) of the RAN to the network node. The method further comprises or initiates at least one of: responsive to a failure of the transmission within the PDB, initiating an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

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 vice versa. The second method and device aspects may be implemented or embodied by the radio device.

The traffic information may comprise a TSCAI (e.g., according to the first and/or second method aspect), which is indicative of traffic patterns of the TSC at a TSN egress of the radio device for data traffic in uplink direction.

The method (e.g., according to the first and/or second method aspect), wherein a flow direction of the TSC is uplink.

The BAT and/or the BET (e.g., according to the first and/or second method aspect), may be defined by the arrival at the radio device, optionally a TSN egress interface of the radio device.

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 first and/or second method aspect 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 second device aspect, a radio device for handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a radio device to a network node of a radio access network (RAN) is provided. The radio device is configured to receive traffic information of the TSC. The traffic information is indicative of a burst arrival time (BAT) and a burst end time (BET). One or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the radio device within a packet delay budget (PDB) of the RAN to the network node. The radio device is further configured to at least one of: responsive to a failure of the transmission within the PDB, initiate an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiate or reinitiate the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

The radio device (e.g., according to the second device aspect) may be configured to perform any one of the steps of the second method aspect.

Alternatively or in addition, the radio device (e.g., according to the second device aspect) may comprise any feature of the first-mentioned device aspect in the claim set.

For example, a user equipment (UE) may implement the radio device.

As to a first device aspect, a network node for handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a network node of a radio access network (RAN) to a radio device is provided. The network node is configured to receive traffic information of the TSC. The traffic information is indicative of a burst arrival time (BAT) and a burst end time (BET). One or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node within a packet delay budget (PDB) of the RAN to the radio device. The network node further configured to at least one of responsive to a failure of the transmission within the PDB, initiating an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

Alternatively or in addition, the network node (e.g., according to the first device aspect) may comprise any feature of the second-mentioned device aspect in the claim set.

For example, a base station configured to communicate with a UE comprises a radio interface and processing circuitry configured to implement the network node according to the first device aspect.

As to a further device aspect a communication system including a host computer comprises processing circuitry configured to provide user data; and a communication interface configured to forward user data to a cellular or ad hoc radio network for transmission to a UE. The UE comprises a radio interface and processing circuitry, the processing circuitry of the UE is configured to execute the steps of the second method aspect.

The communication system (e.g., according to the further device aspect) may further include the UE.

The radio network (e.g., according to the further device aspect) may further comprise a base station, or a radio device functioning as a gateway, which may be configured to communicate with the UE. The base station or the radio device functioning as a gateway may comprises processing circuitry, which may be configured to execute the steps of the first method aspect. The processing circuitry of the host computer (e.g., according to the further device aspect) may be configured to execute a host application, thereby providing the user data. The processing circuitry of the UE (e.g., according to the further device aspect and/or the second device aspect) may be configured to execute a client application associated with the host application.

In at least some embodiments, by initiating the ST timer for the ST responsive to the failure of the transmission within the PDB, a successful transmission in a subsequent burst can be consistent with the fulfillment of the ST counted as starting from the PDB measured after the BET. In same of further embodiments, by initiating or reinitiating the ST timer for the ST responsive to a success of the transmission within the PDB, a subsequent successful transmission can be consistent with the fulfillment of the ST counted as starting from the PDB measured after the BAT or the BET.

At least some method embodiments of any method aspect can select the relay radio device and/or selectively perform a SL connection establishment, which ensures that the traffic relayed by the relay radio device is given the appropriate QoS treatment (e.g., the QoS of the traffic).

Without limitation, for example in a 3GPP implementation, any "radio device" may be a user equipment (UE). Alternatively or in addition, any "network node" may be a base station, optionally a gNB according to 3GPP New Radio (NR)

The technique may be applied in the context of 3GPP NR. While the technique is described for downlink (e.g., according to the first aspects) and uplink (e.g., according to the second aspects), a further method aspect comprises features and/or steps corresponding to the first and/or second methods modified for a sidelink (SL) communication. Unlike a SL according to 3GPP LTE, a SL according to 3GPP NR can provide a wide range of QoS levels. Therefore, at least some embodiments of the technique can ensure that the SL, optionally a relay radio device, handles the ST. The technique may be implemented in accordance with a 3GPP specification, e.g., for 3GPP release 16 or 17. The technique may be implemented for 3GPP NR according to a modification of the 3GPP document 3GPP TS 23.501, V16.6.0.

In any radio access technology (RAT), the technique may be implemented for SL relay selection. The SL may be implemented using proximity services (ProSe), e.g. according to a 3GPP specification.

Any radio device may be a user equipment (UE), e.g., according to a 3GPP specification. The relay radio device may also be referred to as a relay UE (or briefly: relay). Alternatively or in addition, the remote radio device may also be referred to as a remote UE. Alternatively or in addition, the further radio device may also be referred to as a further UE.

The relay radio device and the RAN may be wirelessly connected in an uplink (UL) and/or a downlink (DL) through a Uu interface. Alternatively or in addition, the SL may enable a direct radio communication between proximal radio devices, e.g., the remote radio device and the relay radio device, optionally using a PC5 interface. Services provided using the SL or the PC5 interface may be referred to as proximity services (ProSe). Any radio device (e.g., the remote radio device and/or the relay radio device and/or the further radio device) supporting a SL may be referred to as ProSe-enabled radio device.

The relay radio device may also be referred to as ProSe UE-to-Network Relay.

The remote radio device and/or the relay radio device and/or the RAN and/or the further remote radio device may form, or may be part of, a radio network, e.g., according to the Third Generation Partnership Project (3GPP) 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 remote radio device, the relay radio device and the RAN (e.g., a base station) or the further remote radio device, respectively.

The RAN may comprise one or more base stations, e.g., performing the third 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 the remote radio device and/or the relay radio device and/or the further remote radio device.

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 machinetype communication (MTC), a device for narrowband Internet of Things (NB-loT) 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-loT device include robots, sensors and/or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-loT device may be implemented in a manufacturing plant, household appliances and consumer electronics.

Whenever referring to the RAN, the RAN may be implemented by one or more base stations, e.g., the network node.

The radio device may be wirelessly connected or connectable (e.g., according to a radio resource control, RRC, state or active mode) with the relay radio device and/or the network node (e.g., a base station) of the RAN.

The network node (e.g., a 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 cell, transmission and reception point (TRP), radio access node or access point (AP). The base station and/or the relay radio device may provide a data link to a host computer providing the user data to the remote radio device or gathering user data from the remote radio device. Examples for the base stations may include a 3G base station or Node B, 4G base station or eNodeB, a 5G base station or gNodeB, a Wi-Fi AP and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave).

The RAN 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.

As to a further first device aspect, a device for handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a radio device to a network node of a radio access network (RAN) is provided. The device comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the device is operative to perform any one of the steps of the first method aspect.

As to a second device aspect, a device for handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a radio device to a network node of a radio access network (RAN) is provided. The device may be configured to perform any one of the steps of the second method aspect.

As to a further second device aspect, a device for handling a survival time (ST) for data traffic of a time-sensitive communication (TSC) transmitted from a radio device to a network node of a radio access network (RAN) is provided. The device comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the device is operative to perform any one of the steps of the second method aspect.

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., included in the first and/or second data of the multi-layer transmission. The host computer further comprises a communication interface configured to forward the first and/or second data to a cellular network (e.g., the RAN and/or the base station) for transmission to a UE. A processing circuitry of the cellular network is configured to execute any one of the steps of the first and/or second method aspects. The UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the first and/or second method aspects. The communication system may further include the UE. Alternatively, or in addition, the cellular network may further include one or more base stations 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 method aspects.

The processing circuitry of the host computer may be configured to execute a host application, thereby providing the first and/or second data and/or any host computer functionality described herein. Alternatively, or in addition, the processing circuitry of the UE may be configured to execute a client application associated with the host application.

Any one of the devices, the UE, the base station, 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 aspect.

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 handling a survival time, optionally at a radio device;

Fig. 2 shows a schematic block diagram of an embodiment of a device for handling a survival time, optionally at a network node or RAN;

Fig. 3 shows a flowchart for a method of handling a survival time, which method may be implementable by the device of Fig. 1;

Fig. 4 shows a flowchart for a method of handling a survival time, which method may be implementable by the device of Fig. 2;

Fig. 5 schematically illustrates MAC PDU Assembly and Transmission Time; Fig. 6 illustrates a reference example of an incorrect Survival Time Calculation;

Fig. 7 schematically illustrates a first embodiment of any of the devices of Figs. 1 or 2.

Fig. 8A schematically illustrates a variant of the first embodiment of any of the devices of Figs. 1 or 2.

Fig. 8B schematically illustrates a second embodiment of any of the devices of Figs. 1 or 2.

Fig. 9 shows a schematic block diagram of a remote radio device embodying the device of Fig. 1;

Fig. 10 shows a schematic block diagram of a relay radio device embodying the device of Fig. 2;

Fig. 11 schematically illustrates an example telecommunication network connected via an intermediate network to a host computer;

Fig. 12 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;

Figs. 13 and 14 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; and

Figs. 15 to 17disclose features and steps that combinable with any of the embodiments.

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 an example block diagram of a device according to the second device aspect. The device is generically referred to by reference sign 100.

The device 100 may comprise any one of the units 102 and 104 for performing the steps labelled 302 as well as 304A and/or 304B, respectively, preferably according to the second method aspect or any embodiment disclosed herein.

Any of the units of the device 100 may be implemented by modules configured to provide the corresponding functionality.

The device 100 may also be referred to as, or may be embodied by, the radio device. The device 100 and the network node (e.g., a base station of the RAN) may be in a radio communication (preferably by Uu). Fig. 2 schematically illustrates an example block diagram of a device according to the first device aspect. The device is generically referred to by reference sign 200.

The device 200 may comprise any one of the units 202 and 204 for performing the steps labelled 402 as well as 404A and/or 404B, respectively, preferably according to the first method aspect or any embodiment disclosed herein.

Any of the units of the device 200 may be implemented by modules configured to provide the corresponding functionality.

The device 200 may also be referred to as, or may be embodied by, the RAN or the network node (e.g., a base station) of the RAN and/or of a core network (CN).

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.

The device 100 (e.g., the radio device) and the device 200 (e.g., the network node) may be a radio device and/or a network node (e.g., a base station). Herein, any radio device may be a mobile or portable station and/or any radio device wirelessly connectable to the network node (e.g., a base station) and/or the RAN, or to another radio device. A 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 (loT). 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 sidelink connection. Furthermore, any base station may be a station providing radio access, may be part of a radio access network (RAN) and/or may be a node connected to the RAN for controlling radio access. Further a base station may be an access point, for example a Wi-Fi access point.

Fig. 3 shows an example flowchart for a method 300 according to the second method aspect in the list of claims.

The method 300 may be performed by the device 100. For example, the units 102 and 104 may perform the steps 302 as well as 304A and/or 304B, respectively. Fig. 4 shows an example flowchart for a method 400 according to the first method aspect in the list of claims.

The method 400 may be performed by the device 200. For example, the units 202 and 204 may perform the steps 402 as well as 404A and/or 404B, 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 100 and device 200 may be a radio device or a base station. Herein, any radio device may be a mobile or portable station and/or any radio 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 (loT). 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 base station may be a station providing radio access, 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.

Embodiments can fulfill the Rel-17 RAN work item "Enhanced Industrial Internet of Things (loT) and ultra-reliable and low latency communication (URLLC) support for NR" and/or the following objective on QoS related parameters: RAN enhancements based on new QoS related parameters if any, e.g. survival time, burst spread.

In RAN2#105, RAN2 sent a LS to SA2 (R2-1902354) indicating that the knowledge of a TSN traffic pattern is useful for the gNB to allow it to more efficiently schedule radio resources for TSN traffic using Configured Grants (radio resources allocated for periodic uplink traffic), Semi-Persistent Scheduling (radio resources allocated for periodic downlink traffic) or dynamic grants/assignments (used for aperiodic uplink or downlink traffic). SA2 has correspondingly specified Time Sensitive Communication Assistance Information (TSCAI) in the 3GPP document TS 23.501 consisting of the information shown in Table 1 below (copied from Table 5.27.2-1 of the 3GPP document TS 23.501, version 16.6.0): Table 1: TSC Assistance Information

One problem with the existing TSCAI is that there is no indication regarding when the gNB can expect arrival of the last packet in a set of packets to be aggregated (i.e. the Burst End Time, BET). Without this BET information a gNB is forced to identify a latest point in time (i.e. a "drop dead time") for accepting packets to be aggregated into the next MAC PDU to be sent using the next periodic DRB resource of the corresponding QoS flow. When forced to allocate downlink or uplink DRB resources according to a "drop dead time" the gNB experiences increased constraints regarding where (in the time domain) it can allocate the DRB resources while still ensuring the target Packet Delay Budget (PDB) and Packet Error Rate (PER) attributes of the QoS flow are satisfied (see 5G QoS characteristics described in section 5.7.3 of the 3GPP document TS 23.501, version 16.6.0). This leads to a reduced efficiency for the gNB when managing the available radio resources. Thus, the Burst End time (BET) is proposed as shown in Fig. 5.

Fig. 5 schematically illustrates MAC PDU Assembly and Transmission Time.

An example of the (e.g., first and/or second) bust is indicated at reference sign 502

According to the 3GPP document TS 22.104, survival time (ST) is defined as the time that an application consuming a communication service may continue without an anticipated message. As such, there is the challenge of how to map this application layer definition of ST to MAC layer operation where the transmitting MAC entity receives one or more packets within the time period spanned by BAT and BET and has a limited time available for MAC PDU assembly and transmission, e.g., according to Fig. 5. In the study on "enhanced support of Industrial Internet of Things (I loT) in the 5G System (5GS)" in SA2, one key issue is on the use of the survival time for deterministic application in 5GS. SA2 has discussed how to deliver the survival time to 5G system. How and when to apply survival time assistance information is up to RAN.

The principle in SA2 is that survival Time is transferred as part of the TSCAI parameter but the TSCAI may not always comprise a Survival time parameter. Survival Time is specified by the AF in units of "time" with respect to burst periodicity or as the maximum number of consecutive message transmission failures (i.e. whose loss can be tolerated). It is conveyed to a gNB together with TSCAI Periodicity parameter (the time between periodic TSC bursts, see Table 5.27.2-1 of the 3GPP document TS 23.501, version 16.6.0) and burst size (e.g. MDBV, see section 5.7.3 of the 3GPP document TS 23.501, version 16.6.0).

In the 3GPP document TS 23.501, 5G Access Network Packet Delay Budget (5G- AN PDB) is defined for each packet within a QoS flow, and typically it is counted from the time when the packet is received into the PDCP layer of UE or gNB. A packet is considered as lost once its 5G-AN PDB after reception for transmission expires. Due to the variation of the arrival time of the packets in two different bursts, the time when packet is considered as lost is not consistent in these two bursts. In Rel. 16, TSCAI Burst Arrival Time is not precise due to the fact that the actual provided BAT from the Application Function (AF) in DL is with respect to the ingress port at the UPF side, while the TSCAI for RAN is with respect to the ingress of gNB. To change the reference, TSCAI BAT = BAT at ingress port plus the 5G-CN PDB. 5G-CN PDB is the upper bound of the delay in the core network. In consequence, TSCI Al Burst Arrival Time is an upper bound for the latest possible time when the first packet of the burst can arrive.

This may lead to survival time being wrongly calculated. One example of ST measurement is illustrated in Fig. 6 below where an ST timer is started at the end of a PDB for which the packet transmission failure occurs. It leaves a reduced amount of time for the packet arriving late in the second burst to be successfully delivered in order to meet the survival time requirement (i.e., to ensure successful delivery of the packet arriving in the second burst prior to expiry of the ST timer, it must be successfully transmitted way before the end of the full time period allowed by its corresponding PDB). This problem occurs because the packet in the second burst arrives close to the burst end time while the packet in the first burst arrives close to the burst arrival time and because the ST timer is started upon the detection of packet transmission failure at the end of the time period allowed by the PDB.

Fig. 6 illustrates an incorrect Survival Time Calculation, using an example Survival Time that corresponds to one burst period. The example can be extended without loss of generality to a survival time that is larger.

Any of the following embodiments are disclosed as such and in combination with any one of the embodiments in the list of claims.

In a first embodiment, to address the above lack of clarity regarding ST timer management at the RAN, the survival time is counted as starting from the PDB measured after the burst end time, e.g., as illustrated in Fig. 7.

Fig. 7 schematically illustrates a correct Survival Time (ST) calculation, which may be implemented in any embodiment.

In this way, it accounts for the possible latest arrival time in the subsequent bursts and thus the survival time can make sense for RAN (meaning that RAN can utilize knowledge of survival time state in order to more robustly schedule packets of the subsequent burst). In other words, by starting the ST timer at the end of the PDB measured from the end of a burst, the full time period allowed by the PDB can be utilized for packet transmission. To summarize, in a first independent embodiment, if not started already, the survival time starts when a message is declared as failed and it is equal to the burst end time (BET) plus 5G- AN PDB. In other words, the embodiment means that RAN applies additional robustness mechanisms to ensure delivery of the subsequent packet during [BAT, BET + 5G-AN PDB] for the case where survival time equals burst period.

In another dependent embodiment, if the message is segmented into multiple packets/frames sent to RAN, the message is declared as failed if not all segments of a message is delivered before the time equal to burst end time (BET) plus 5G- AN PDB. The message is declared as success if all segments of a message are delivered before the time equal to burst end time (BET) plus 5G-AN PDB. In a follow-up embodiment, upon the setup of the QoS flow, the setup of the PDB of the QoS flow considers the burst end time. Since the start of the burst occurs at BAT, this approach requires that the PDB value included in 5G QoS characteristics indicate the maximum time remaining for all (aggregated) packets within the burst to be delivered to thereby ensure a packet arriving at the start of the burst is still delivered within the PDB even though PDB is measured from the end of the burst (e.g. if PDB is to be measured from the end of a burst then it may need to be reduced by the time between BAT and BET, compared to when PDB is to be measured from the start of the burst in which BET is not part of the TSC Al).

In another dependent embodiment, by implementation, both UE and gNB deliver the packet even if the packets have been delayed more than PDB. For the delay critical GBR resource type, packets delayed more than the PDB can be discarded or delivered depending on local decision, although they are counted as loss in the packet error ratio correction. This approach is to tackle that, in some cases, the survival time may end slightly after the PDB of the packet, see figure 3 as an example.

In one embodiment, ST and ST timer are managed at the MAC layer and one assembled MAC PDU is used to transmit the set of one or more packets. If the MAC PDU is not delivered within the PDB, then the message is declared as lost. If the MAC PDU is delivered within the PDB, then the message is declared as success.

In another embodiment, ST and ST timer are managed at the PDCP layer and one or more MAC PDUs might be used to transmit the set of one or more packets. Thus, if all MAC PDUs are received successfully within the PDB of the message, the message is declared as success. Otherwise, the message is declared as lost. The detection of the message failure can be managed by a PDCP discard timer. Whether survival time timer is started at the point in time discussed above (e.g. after BET + 5G AN PDB according to first embodiment), depends on whether the application layer message of the burst is considered successfully delivered. Failure of successful delivery can be identified by the transmitting node for data unit part of the message/burst, by at least one of: not receiving positive HARQ feedback within the 5G AN PDB no or negative HARQ. feedback, and not being able to retransmit HARQ TB within 5G AN PDB not receiving positive RLC status report feedback within 5G AN PDB no or negative RLC status report feedback, and not being able to retransmit RLC PDU within 5G AN PDB no transmission attempt done (e.g. due to queueing or discarding) within 5G AN PDB

There are two alternative metric definitions for survival time in the 3GPP document TR 23.700-20, version 1.0.0: a) in units of "time" with the timescale corresponding to burst periodicity; b) as the maximum number of consecutive message transmission failures.

The above embodiments are functionally the same for both options "a" and "b". In case of option "a", the survival time starts (if not already) at time = burst end time (BET) plus 5G-AN PDB (if the message is not successfully delivered before that time). Any integer number of burst periods after this start time, which is determined using the value of "a" provided Survival time parameter, is the time that coincides with the end of BET plus 5G-AN PDB for another later burst which is also the time to define a successful message delivery for that later burst. As long as any later message is delivered successfully before expiration of the survival time, the survival time timer is stopped, and no further action is taken. If a later message is not successfully delivered prior to expiration of the survival time, then a gNB determines that a survival time violation has occurred.

In case of option "b", the message is counted as failed if it is not delivered before its burst end time (BET) plus 5G-AN PDB.

The embodiments may, alternatively or in addition, comprise the features illustrated in Fig. 8A.

In another independent embodiment for ST management (e.g., according to the second alternative of any one of the aspects), the survival time is started/re- started whenever a message is declared as successfully delivered (i.e., by the end of the time period determined by the burst arrival time (BAT) plus 5G-AN PDB, e.g., as illustrated in Fig. 8B). If the maximum time of message losses allowed by the survival time is reached, then a survival time violation has occurred. In this embodiment, when the survival time is provided together with TSCAI, the PDB for delay critical GBR resource type is counted from the burst arrival time but not the actual packet arrival time. With this approach, the message is declared as failed when any segments fail to meet the PDB (i.e., the message delivery fails) and the message is declared as success when all segments are delivered successfully.

This approach allows PDB to reflect the case of the expected earliest possible arrival of a packet within a burst. With this approach, even though ST is technically an application layer attribute, it gets mapped to MAC layer operation at the transmitting node (i.e. a gNB or a UE) by viewing it as the maximum time allowed from the end of the PDB associated with the successful transmission of a message until the next successful transmission of a message. This approach therefore avoids the complexity of the 1st approach wherein the PDB value (included in 5G QoS characteristics) may need to be reduced by the time between BAT and BET. This approach does not rely on any implementation as discussed above (i.e., not discarding packet after PDB) since it is based on ensuring the time starting from the last successful message delivery does not exceed the maximum time allowed as indicated by survival time parameter in TSCAI.

Fig. 9 shows a schematic block diagram for an embodiment of the device 100. The device 100 comprises processing circuitry, e.g., one or more processors 904 for performing the method 300 and memory 906 coupled to the processors 904. For example, the memory 906 may be encoded with instructions that implement at least one of the modules 102 and 104.

The one or more processors 904 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 906, transmitter and/or radio device functionality. For example, the one or more processors 904 may execute instructions stored in the memory 906. 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. 9, the device 100 may be embodied by a radio device 900, e.g., functioning as a UE. The radio device 900 comprises a radio interface 902 coupled to the device 100 for radio communication with one or more receiving stations, e.g., functioning as a network node (e.g., base station).

Fig. 10 shows a schematic block diagram for an embodiment of the device 200. The device 200 comprises processing circuitry, e.g., one or more processors 1004 for performing the method 400 and memory 1006 coupled to the processors 1004.

For example, the memory 1006 may be encoded with instructions that implement at least one of the modules 202 and 204.

The one or more processors 1004 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 1006, receiver and/or network node functionality. For example, the one or more processors 1004 may execute instructions stored in the memory 1006. 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. 10, the device 200 may be embodied by a network node 1000, e.g., functioning as a base station. The receiving station 1000 comprises a radio interface 1002 coupled to the device 200 for radio communication with one or more radio device, e.g., functioning as UEs.

With reference to Fig. 11, in accordance with an embodiment, a communication system 1100 includes a telecommunication network 1110, such as a 3GPP-type cellular network, which comprises an access network 1111, such as a radio access network, and a core network 1114. The access network 1111 comprises a plurality of base stations 1112a, 1112b, 1112c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1113a, 1113b, 1113c. Each base station 1112a, 1112b, 1112c is connectable to the core network 1114 over a wired or wireless connection 1115. A first user equipment (UE) 1191 located in coverage area 1113c is configured to wirelessly connect to, or be paged by, the corresponding base station 1112c. A second UE 1192 in coverage area 1113a is wirelessly connectable to the corresponding base station 1112a. While a plurality of UEs 1191, 1192 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 1112.

Any of the base stations 1112 and the UEs 1191, 1192 may embody the device 100.

The telecommunication network 1110 is itself connected to a host computer 1130, 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 1130 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 1121, 1122 between the telecommunication network 1110 and the host computer 1130 may extend directly from the core network 1114 to the host computer 1130 or may go via an optional intermediate network 1120. The intermediate network 1120 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1120, if any, may be a backbone network or the Internet; in particular, the intermediate network 1120 may comprise two or more sub-networks (not shown).

The communication system 1100 of Fig. 11 as a whole enables connectivity between one of the connected UEs 1191, 1192 and the host computer 1130. The connectivity may be described as an over-the-top (OTT) connection 1150. The host computer 1130 and the connected UEs 1191, 1192 are configured to communicate data and/or signaling via the OTT connection 1150, using the access network 1111, the core network 1114, any intermediate network 1120 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1150 may be transparent in the sense that the participating communication devices through which the OTT connection 1150 passes are unaware of routing of uplink and downlink communications. For example, a base station 1112 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1130 to be forwarded (e.g., handed over) to a connected UE 1191. Similarly, the base station 1112 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1191 towards the host computer 1130.

By virtue of the method 300 or 400 being performed by any one of the UEs 1191 or 1192 and/or any one of the base stations 1112, the performance or range of the OTT connection 1150 can be improved, e.g., in terms of increased throughput and/or reduced latency. More specifically, the host computer 1130 may indicate to the RAN or the (e.g., relay) radio device 100 or the (e.g., remote) radio device 100 (e.g., on an application layer) the QoS of the traffic.

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. 12. In a communication system 1200, a host computer 1210 comprises hardware 1215 including a communication interface 1216 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1200. The host computer 1210 further comprises processing circuitry 1218, which may have storage and/or processing capabilities. In particular, the processing circuitry 1218 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 1210 further comprises software 1211, which is stored in or accessible by the host computer 1210 and executable by the processing circuitry 1218. The software 1211 includes a host application 1212. The host application 1212 may be operable to provide a service to a remote user, such as a UE 1230 connecting via an OTT connection 1250 terminating at the UE 1230 and the host computer 1210. In providing the service to the remote user, the host application 1212 may provide user data, which is transmitted using the OTT connection 1250. The user data may depend on the location of the UE 1230. The user data may comprise auxiliary information or precision advertisements (also: ads) delivered to the UE 1230. The location may be reported by the UE 1230 to the host computer, e.g., using the OTT connection 1250, and/or by the base station 1220, e.g., using a connection 1260. The communication system 1200 further includes a base station 1220 provided in a telecommunication system and comprising hardware 1225 enabling it to communicate with the host computer 1210 and with the UE 1230. The hardware 1225 may include a communication interface 1226 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1200, as well as a radio interface 1227 for setting up and maintaining at least a wireless connection 1270 with a UE 1230 located in a coverage area (not shown in Fig. 12) served by the base station 1220. The communication interface 1226 may be configured to facilitate a connection 1260 to the host computer 1210. The connection 1260 may be direct, or it may pass through a core network (not shown in Fig. 12) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1225 of the base station 1220 further includes processing circuitry 1228, 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 1220 further has software 1221 stored internally or accessible via an external connection.

The communication system 1200 further includes the UE 1230 already referred to. Its hardware 1235 may include a radio interface 1237 configured to set up and maintain a wireless connection 1270 with a base station serving a coverage area in which the UE 1230 is currently located. The hardware 1235 of the UE 1230 further includes processing circuitry 1238, 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 1230 further comprises software 1231, which is stored in or accessible by the UE 1230 and executable by the processing circuitry 1238. The software 1231 includes a client application 1232. The client application 1232 may be operable to provide a service to a human or non-human user via the UE 1230, with the support of the host computer 1210. In the host computer 1210, an executing host application 1212 may communicate with the executing client application 1232 via the OTT connection 1250 terminating at the UE 1230 and the host computer 1210. In providing the service to the user, the client application 1232 may receive request data from the host application 1212 and provide user data in response to the request data. The OTT connection 1250 may transfer both the request data and the user data. The client application 1232 may interact with the user to generate the user data that it provides.

It is noted that the host computer 1210, base station 1220 and UE 1230 illustrated in Fig. 12 may be identical to the host computer 1130, one of the base stations 1112a, 1112b, 1112c and one of the UEs 1191, 1192 of Fig. 11, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 12, and, independently, the surrounding network topology may be that of Fig. 11.

In Fig. 12, the OTT connection 1250 has been drawn abstractly to illustrate the communication between the host computer 1210 and the UE 1230 via the base station 1220, 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 1230 or from the service provider operating the host computer 1210, or both. While the OTT connection 1250 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 1270 between the UE 1230 and the base station 1220 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 1230 using the OTT connection 1250, in which the wireless connection 1270 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 1250 between the host computer 1210 and UE 1230, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1250 may be implemented in the software 1211 of the host computer 1210 or in the software 1231 of the UE 1230, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1250 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 1211, 1231 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1250 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1220, and it may be unknown or imperceptible to the base station 1220. 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 1210 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 1211, 1231 causes messages to be transmitted, in particular empty or "dummy" messages, using the OTT connection 1250 while it monitors propagation times, errors etc.

Fig. 13 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. 11 and 12. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this paragraph. In a first step 1310 of the method, the host computer provides user data. In an optional substep 1311 of the first step 1310, the host computer provides the user data by executing a host application. In a second step 1320, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1330, 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 1340, the UE executes a client application associated with the host application executed by the host computer.

Fig. 14 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. 11 and 12. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this paragraph. In a first step 1410 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 1420, 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 1430, the UE receives the user data carried in the transmission.

Figs. 15 to 17 disclose features and steps that may be combined with any of the embodiments described herein.

Fig. 15 schematically illustrates a time domain.

Segments can arrive at any point in the burst 502 or 504. The below interpretation 2 (e.g., as illustrated in Fig. 17) is not flexible, as the first segment in the second cycle might arrive in the later part of the burst.

1. If gNB 200 detects the first segement is lost after PDB, then gNB 200 understands that the whole message has to be received at the latest t3+survival time.

2. If gNB 200 detects the first segement is lost after PDB, then gNB 200 understands that the whole message has to be received at tl+survival time.

Alternatively or in addition, e.g., as schematically illustrated in Fig. 16, Packets can arrive at any point in the burst (e.g., 502 or 504). The suppose survival time may be one burst period (i.e., from one burst start to the next burst start). There are two interpretations of the survival time and 2nd one may be viewed as not flexible:

1. If gNB 200 detects the packet is not delivered after PDB at tl, then gNB 200 understands that the next packet has to be delivered at the latest t3+survival time.

2. If gNB 200 detects the packet is not delivered after PDB at tl, then gNB understands that the next packet has to be delivered at tl+survival time.

As has become apparent from above description, at least some embodiments of the technique allow for an improved radio resource efficiency and/or latency and/or power consumption.

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

37

Claims

1. A method (400) of handling a survival time, ST, for data traffic of a timesensitive communication, TSC, transmitted from a network node (200) of a radio access network, RAN, to a radio device (100), the method (400) comprising or initiating receiving (402) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node (200) within a packet delay budget, PDB, of the RAN to the radio device (100), the method (400) further comprising or initiating at least one of: responsive to a failure of the transmission within the PDB, initiating (404A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating (404B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

2. The method (400) of claim 1, wherein the initiating (404) of the ST timer is triggered upon expiry of the PDB as measured after the BET.

3. The method (400) of claim 1 or 2, wherein the ST timer is initiated if the transmission fails within the PDB as measured after the BET.

4. The method (400) of any one of claims 1 to 3, wherein the ST is independent of a time of arrival of the one or more data packets between the BAT and the BET.

5. The method (400) of any one of claims 1 to 4, wherein the one or more data packets arrive at the network node (200) between the BAT and the BET.

6. The method (400) of any one of claims 1 to 5, wherein the one or more data packets are to be transmitted by the network node (200) within the PDB of the RAN measured after the arrival of the respective one of the one or more data packets or within the PDB measured after the arrival of the last one of the one or more data packets. 38

7. The method (400) of any one of claims 1 to 6, wherein the data traffic comprises a plurality of periodic bursts (502, 504), wherein the BAT and the BET are indicative of the burst arrival time and the burst end time of a first burst (502) of the periodic bursts (502, 504), the method (400) further comprising: transmitting one or more further data packets of the data traffic that arrived in a second burst (504) of the periodic bursts (502, 504) after the first burst (502), wherein the one or more further data packets are transmitted by the network node (200) within the PDB of the RAN to the radio device (100).

8. The method (400) of claim 7, wherein the second burst (504) is subsequent to the first burst (502) in the plurality of periodic bursts (502, 504).

9. The method (400) of claim 7 or 8, wherein the one or more further data packets, which are transmitted in the PDB after the second burst (504), are declared and/or counted as a successful transmission.

10. The method (400) of any one of claims 7 to 9, wherein the one or more further data packets, which are transmitted in the PDB after the second burst (504), are transmitted at the network node (200) and/or received at the radio device (100) prior to expiry of the ST timer.

11. The method (400) of any one of claims 7 to 10, wherein the ST is equal to or is an integer multiple of a periodicity of the periodic bursts (502, 504) in the TSC.

12. The method (400) of any one of claims 1 to 11, wherein the one or more data packets belong to a Quality of Service, QoS, flow of the TSC, and wherein the QoS flow is associated with the PDB.

13. The method (400) of any one of claims 1 to 12, wherein the BAT is the latest possible time of arrival of a first data packet of the one or more data packets at the RAN or at the network node (200), optionally at a time sensitive networking ingress of the RAN or of the network node (200). 14. The method (400) of any one of claims 1 to 13, wherein the BET is the latest possible time of arrival of a last data packet of the one or more data packets at the RAN or at the network node (200), optionally at a time sensitive networking ingress of the RAN or of the network node (200).

15. The method (400) of any one of claims 1 to 14, wherein the one or more data packets for which the transmission failed within the PDB are declared and/or counted as lost or failed.

16. The method (400) of any one of claims 1 to 15, wherein the one or more data packets belong to single message of the TSC.

17. The method (400) of any one of claims 1 to 16, wherein a message in the TSC is segmented into the data packets.

18. The method (400) of claim 17, wherein the message is declared and/or counted as lost or failed, if the transmission of at one of the data packets failed within the PDB.

19. The method (400) of any one of claims 1 to 18, wherein the traffic information message is further indicative of the ST.

20. The method (400) of any one of claims 1 to 19, wherein the ST is counted as starting from the BET plus the duration of the PDB.

21. The method (400) of any one of claims 1 to 20, wherein traffic information is or comprises a TSC assistance information, TSCAI.

22. The method (400) of claim 21, wherein the TSCAI is indicative of at least one of: a flow direction of the TSC; a periodicity of bursts (502, 504) in the TSC; the BAT; and the BET.

23. The method (400) of any one of claims 1 to 22, wherein a flow direction of the TSC is downlink.

24. The method (400) of any one of claims 1 to 23, wherein the transmission or an attempt of the failed transmission of the one or more data packets comprises: assembling the one or more data packets in a medium access control, MAC, packet data unit, PDU, for the transmission or the attempt of the failed transmission.

25. The method (400) of any one of claims 1 to 24, wherein the transmission of the one or more further data packets comprises: assembling the one or more further data packets in a medium access control, MAC, packet data unit, PDU, for the transmission.

26. The method (400) of any one of claims 1 to 25, wherein the survival time, ST, is measured and/or computed relative to the BET plus the duration of the PDB. 1. The method (400) of any one of claims 1 to 26, wherein the ST timer is initiated at expiry of the PDB as measured from the BET.

28. The method (400) of any one of claims 1 to 1 , wherein the PDB is a maximum delay of the traffic in the RAN.

29. The method (400) of any one of claims 1 to 28, wherein the PDB is defined for each data packet within a QoS flow.

30. The method (400) of any one of claims 1 to 29, wherein the RAN, optionally the network node (200), schedules the radio device (100) for the data traffic of the TSC based on at least one of the traffic information and the TSCAI.

31. The method (400) of any one of claims 1 to 30, wherein the RAN, optionally the network node (200), schedules the radio device (100) for the data traffic of the TSC using at least one of: semi-persistent scheduling, SPS; dynamic assignments; configured grants; and dynamic grants.

32. The method (400) of any one of claims 1 or 31, wherein the ST is at least one of computed and received for a Quality of Service, QoS, flow of the TSC.

33. The method (400) of any one of claims 1 or 32, wherein the TSC is integrated transparently as a bridge in a time-sensitive networking, TSN, network. 34. The method (400) of any one of claims 1 or 33, wherein at least one of the traffic information and the TSCAI is indicative of traffic patterns of the data traffic of the TSC at a TSN ingress of the RAN, optionally a TSN ingress of the network node (200), for the data traffic in downlink direction.

35. The method (400) of any one of claims 1 or 34, wherein at least one of the traffic information and the TSCAI is associated with at least one of a data packet unit, PDU, session of the TSC and a Quality of Service, QoS, flow of the TSC.

36. The method (400) of any one of claims 1 or 35, wherein at least one of the traffic information and the TSCAI are received from a Session Management Function, SMF, at the RAN and/or at the network node (200), optionally upon setup or establishment of the QoS Flow for the radio device (100).

37. The method (400) of any one of claims 1 to 36, wherein the success or failure of the transmission of any one of the one or more data packets is determined by an extended PDB as measured from the time of arrival of the respective packet, wherein the extended PDB includes the time remaining between the time of arrival of the respective packet and the BET.

38. The method (400) of any one of claims 1 to 37, wherein the success or failure of the transmission of any one of the one or more data packets is determined by a reduced PDB as measured from the time of arrival of the respective packet, wherein the reduced PDB is reduced by the time difference between the BAT and the BET.

39. The method (400) of any one or claims 1 to 38, wherein the network node transmits at least one of the one or more data packets or the one or more further data packets after the PDB measured from the time of arrival of the respective packet.

40. The method (400) of claim 39, wherein the at least one data packet transmitted after the PDB measured from the time of arrival of the respective packet is declared and/or counted as a successful transmission, if the at least one data packet is transmitted by the network node (200) and/or received by the radio device (100) within the ST and/or within the PDB measured from the BET. 42

41. The method (400) of any one of claims 1 to 40, wherein the ST timer is associated with the data packet, the transmission of which failed, or wherein the ST timer is associated with the message the transmission of which failed.

42. The method (400) of any one of claims 1 to 41, wherein at least one of the ST timer and the ST are implemented as a MAC layer of the network node (200).

43. The method (400) of any one of claims 1 to 42, wherein the success or failure of the transmission of the one or more data packets depends on whether one MAC PDU assembled to comprise the one or more data packets is transmitted within the PDB, optionally measured from the BET.

44. The method (400) of any one of claims 1 to 43, wherein at least one of the ST timer and the ST are implemented as a packet data convergence protocol, PDCP, layer of the network node (200).

45. The method (400) of any one of claims 1 to 44, wherein the success or failure of the transmission of the one or more data packets depends on whether one or more MAC PDUs comprising the one or more data packets are transmitted within the PDB, optionally measured from the BET.

46. The method (400) of claims 44 and 45, wherein the failure of the transmission of the one or more data packets is determined using a PDCP discard timer of the PDCP layer.

47. The method (400) of any one of claims 1 to 46, wherein the failure or the failure of the transmission within the PDB is triggered by at least one of:

- not receiving a positive hybrid automatic repeat request, HARQ, feedback within the PDB;

- receiving no HARQ feedback or a negative HARQ feedback, optionally and not being able to retransmit a HARQ transport block within the PDB;

- not receiving a positive radio link control, RLC, status report feedback within the PDB;

- receiving no or negative RLC status report feedback, optionally and not being able to retransmit an RLC PDU within the PDB;

- not attempting to transmit the one or more data packets within the PDB, optionally due to queueing or discarding of the one or more data packets. 43

48. The method (400) of any one of claims 1 to 47, wherein the ST is defined in units of time, optionally corresponding to the periodicity of the periodic bursts (502, 504).

49. The method (400) of any one of claims 1 to 48, wherein the ST is defined as the maximum number of consecutive failures of the transmission of the data packets or the message.

50. A method (300) of handling a survival time, ST, for data traffic of a timesensitive communication, TSC, transmitted from a radio device (100) to a network node (200) of a radio access network, RAN, the method (300) comprising or initiating receiving (302) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the radio device (100) within a packet delay budget, PDB, of the RAN to the network node (200), the method (300) further comprising or initiating at least one of: responsive to a failure of the transmission within the PDB, initiating (304A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating (304B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

51. The method (300) of claim 50, wherein the traffic information comprises a TSCAI, which is indicative of traffic patterns of the TSC at a TSN egress of the radio device (100) for data traffic in uplink direction.

52. The method (300) of claim 50 or 51, wherein a flow direction of the TSC is uplink.

53. The method (300) of any one of claims 50 to 52, wherein the BAT and/or the BET are defined by the arrival at the radio device (100), optionally a TSN egress interface of the radio device. 44

54. The method (300) of any one of claims 50 to 53, further comprising the steps or features of any one of claims 2 to 49 or any step or feature corresponding thereto.

55. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 49 and/or claims 50 to 54 when the computer program product is executed on one or more computing devices (1104; 1204), optionally stored on a computer-readable recording medium (1106; 1206).

56. A radio device (100) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the radio device (100) is operable to: receive (302) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the radio device (100) within a packet delay budget, PDB, of the RAN to the network node (200), the radio device (100) being further operative to at least one of: responsive to a failure of the transmission within the PDB, initiating (304A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating (304B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

57. The radio device (100; 1100; 1291; 1292; 1330) of claim 56, further operable to perform the steps of any one of claims 50 to 54.

45

58. A radio device (100) for handling a survival time, ST, for data traffic of a time-sensitive communication, TSC, transmitted from a radio device (100) to a network node (200) of a radio access network, RAN, the radio device (100) being configured to: receive (302) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the radio device (100) within a packet delay budget, PDB, of the RAN to the network node (200), the radio device (100) being further configured to at least one of: responsive to a failure of the transmission within the PDB, initiating (304A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating (304B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

59. The radio device (100; 1100; 1291; 1292; 1330) of claim 58, further configured to perform the steps of any one of claims 50 to 54.

60. A user equipment, UE, (100; 900; 1191; 1192; 1230) implementing the radio device according to any one of claims 56 to 59.

61. A network node (200) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node (200) is operable to: receive (402) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node (200) within a packet delay budget, PDB, of the RAN to the radio device (100), the network node (200) further being operable to at least one of: responsive to a failure of the transmission within the PDB, initiating (404A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and 46 responsive to a success of the transmission within the PDB, initiating or reinitiating (404B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

62. The network node (200) of claim 61, further operable to perform any one of the steps of any one of claims 2 to 49.

63. A network node (200) for handling a survival time, ST, for data traffic of a time-sensitive communication, TSC, transmitted from a network node (200) of a radio access network, RAN, to a radio device (100), the network node (200) being configured to receive (402) traffic information of the TSC, the traffic information being indicative of a burst arrival time, BAT, and a burst end time, BET, wherein one or more data packets of the data traffic that arrive between the BAT and the BET are to be transmitted by the network node (200) within a packet delay budget, PDB, of the RAN to the radio device (100), the network node (200) further being configured to at least one of: responsive to a failure of the transmission within the PDB, initiating (404A) an ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BET; and responsive to a success of the transmission within the PDB, initiating or reinitiating (404B) the ST timer for the ST, wherein the ST is counted as starting from the PDB measured after the BAT or the BET.

64. The network node (200) of claim 63, further configured to perform the steps of any one of claim 2 to 49.

65. A base station (200; 1000; 1112; 1220) configured to communicate with a user equipment, UE, the base station (200; 1000; 1112; 1220) comprising a radio interface (1002; 1227) and processing circuitry (1004; 1228) configured to implement the network node according to any one of the claims 61 to 64.

66. A communication system (1100; 1200) including a host computer (1330; 1410) comprising: processing circuitry (1218) configured to provide user data; and 47 a communication interface (1216) configured to forward user data to a cellular or ad hoc radio network (1110) for transmission to a user equipment, UE, (100; 900; 1191; 1192; 1230) wherein the UE (100; 900; 1191; 1192; 1230) comprises a radio interface (1102; 1437) and processing circuitry (1104; 1438), the processing circuitry (904; 1238) of the UE (100; 900; 1191; 1192; 1230) being configured to execute the steps of any one of claims 50 to 54.

67. The communication system (1100; 1200) of claim 66, further including the UE (100; 900; 1191; 1192; 1230).

68. The communication system (1100; 1200) of claim 66 or 67, wherein the radio network (1310) further comprises a base station (200; 1000; 1112; 1220), or a radio device (100; 900; 1191; 1192; 1230) functioning as a gateway, which is configured to communicate with the UE (100; 900; 1191; 1192; 1230).

69. The communication system (1100; 1200) of claim 68, wherein the base station (200; 1000; 1112; 1220), or the radio device (100; 900; 1191; 1192; 1230) functioning as a gateway, comprises processing circuitry (1004; 1228), which is configured to execute the steps of claim 1 to 49.

70. The communication system (1100; 1200) of any one of claims 66 to 69, wherein: the processing circuitry (1218) of the host computer (1130; 1210) is configured to execute a host application (1212), thereby providing the user data; and the processing circuitry (904; 1238) of the UE (100; 900; 1191; 1192; 1230) is configured to execute a client application (1232) associated with the host application (1212).