WO2024117952A1

WO2024117952A1 - Method performed by a communication device comprising a protocol stack, receiving an indication from an upper layer to clear data in a buffer which data have not been yet submitted to one or more layers below the layer

Info

Publication number: WO2024117952A1
Application number: PCT/SE2022/051133
Authority: WO
Inventors: Massimo CONDOLUCI; Giampaolo CUOZZO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-12-02
Filing date: 2022-12-02
Publication date: 2024-06-06

Abstract

Embodiments herein relate to, for example, a method performed by a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communications device receives at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer or transmitted to a receiving device. The communication device further removes the data from the buffer.

Description

METHOD PERFORMED BY A COMMUNICATION DEVICE COMPRISING A PROTOCOL STACK, RECEIVING AN INDICATION FROM AN UPPER LAYER TO CLEAR DATA IN A BUFFER WHICH DATA HAVE NOT BEEN YET SUBMITTED TO ONE OR MORE LAYERS BELOW THE LAYER

TECHNICAL FIELD

Embodiments herein relate to communication devices and methods performed

5 therein regarding communication. Furthermore, a computer program product and a computer-readable storage medium are also provided herein. In particular, embodiments herein relate to handling communication, such as handling or managing data or packets of an application, in a communications network.

10 BACKGROUND

In a typical communications network, user equipments (UE), also known as wireless communication devices, mobile stations, stations (STA) and/or wireless devices, communicate via a Radio Access Network (RAN) with one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cells, with

15 each service area or cell being served by a radio network node such as an access node, e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB. The service area or cell is a geographical area where radio coverage is provided by the radio network node. The radio network node operates on radio frequencies to communicate over an air interface with the

20 UEs within range of the radio network node. The radio network node communicates over a downlink (DL) to the UE and the UE communicates over an uplink (UL) to the radio network node.

A Universal Mobile Telecommunications System (UMTS) is a third generation (3G) telecommunication network, which evolved from the second generation (2G) Global

25 System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High-Speed Packet Access (HSPA) for communication with user equipment. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for present and future generation networks

30 and investigate, e.g., enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. The RNCs are typically connected to one or more core networks.

Specifications for the Evolved Packet System (EPS) have been completed within the 3GPP and coming 3GPP releases, such as New Radio (NR), are worked on. The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E- UTRAN/LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network. As such, the Radio Access Network (RAN) of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks.

With the emerging 5G technologies such as new radio (NR), the use of very many transmit- and receive-antenna elements may be of great interest as it makes it possible to utilize beamforming, such as transmit-side and receive-side beamforming. Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions. Similarly, on the receive-side, a receiver can amplify signals from a selected direction or directions, while suppressing unwanted signals from other directions.

A communication background considered herein is shown in Fig. 1. The application layer can be considered as logic of an application server. From a communication perspective, the application generates data or data models which are delivered to lower layers for transmission and receives data, e.g., models, from lower layers. The application layer could use a transport layer such as transport control protocol (TCP), Quick user datagram protocol (UDP) Internet Connections (QUIC), to have a reliable and in-order delivery, or protocols such as UDP. From a transmission perspective, the transport layer fetches data from the application layer, processes them, e.g., adding header, and delivers to lower layer - if reliable delivery is ON, data submitted to lower layers are kept until they have been acknowledged. It could happen that the transport layer buffers data not yet delivered to lower layers, e.g., IP layer, e.g., data already processed to speed up their transmission but that cannot be delivered as transmission buffer, e.g., associated to congestion window size is already full, see patterned portion of data in Fig. 1 . For communication over mobile networks, data submitted to lower layers by the transport protocol reach the RAN layers, i.e., Service Data Adaption Protocol (SDAP), Packet Data Convergence Protocol (PDCP), radio link control (RLC) or Medium Access Control (MAC), Physical layer (PHY), at either device-side or network side, e.g., base station.

RAN layers could have several buffers. For example, PDCP could have buffers where it keeps packets that have been received from upper layers, e.g., IP layer, and that have been processed, secured, adding header, etc., but not yet delivered to lower layers e.g., RLC. That data has not been delivered to lower layers may be because RLC buffers could be full or to reduce jitter for separate central unit (CU) or distributed unit (DU) deployments, or to balance traffic among multiple legs in case of dual-connectivity, or for recovering packets during mobility events. As well, RLC could have buffers where data are kept before being delivered to lower layers e.g., MAC. In particular, if RLC works in acknowledged mode (AM), it will keep data which have been delivered to MAC while waiting for such data to be acknowledged. Furthermore, it will also buffer data already processed to keep them ready to be delivered to MAC when radio resources are available, see patterned portion of data in Fig. 1. Further buffers could be present at other layers, e.g., MAC, although layers such as PDCP or RLC are usually buffering more data compared to layers such as MAC.

For simplicity, in Fig. 1 it is depicted that data delivered to lower layer and awaiting to being acknowledged and data not yet delivered to lower layer are somehow within the same buffer. This is valid logically, but it could be that in practical implementation different buffers could be used, e.g., a first buffer is used to store data processed but not yet delivered to lower layers and a second is used to store data already delivered to lower layers but awaiting to be acknowledged.

SUMMARY

As part of developing embodiments herein one or more problems have been identified. Considering the stack transmission overview in Fig. 1 , one problem that arises is that, even if the application layer stops the transmission of data related to a certain set of information previously generated, for example, data related to a previous version or model, the communication stack could still have data in different layers relevant to the information previously generated. This problem is shown from a high-level perspective in Fig. 2, wherein data, v.(X), is exemplified as data related to a certain set or version of information previously generated.

From Fig. 2 it is shown that the application layer started transmitting data relevant to version v.(X), i.e., data starts to be delivered to lower layers. Depending on the size of data or amount of data and size of buffers at lower layers and their configuration, it could be that data or a whole model is delivered to lower layers. When a lower layer, e.g., a transport layer such as TCP/QUIC or a RAN layer such as PDCP/RLC, gets data to be transmitted, such data are processed and stored in their respective buffers awaiting for the subsequent delivery to their respective lower layers. The application layer logic could decide that it is not necessary anymore to continue with the transmission of data relevant to version v.(X), for example: (i) from a device side, it could be that a newer version is employed or that an information that a newer version is available has been received; (ii), from a training server side of models, it could be that a model with a newer version has been generated, or that enough inputs for generating a newer version have been received. If this happens, the application layer logic could stop providing the lower layers with data relevant to version v.(X) and instead start providing data relevant to the newer version v.(X+1). Nevertheless, lower layers will still have buffered data related to version v.(X) which are now not relevant for transmission anymore from an application logic perspective, but this is not visible to, e.g., transport/RAN layers which will proceed with transmitting such data which are now not relevant from an application logic point of view.

The implications of the problem shown Fig. 2 may be one or more of the following:

• From a model learning perspective, this will involve delays in completing a certain iteration. In a first example, if a device has still data to be transmitted relevant to a model v.(X) while a newer model v.(X+1) should be transmitted instead, a training server will experience delay with receiving the newer trained model and consequently delay in triggering model aggregation. In a second example, if a training server has a newer model v.(X+1) to send to a device but there are buffered data relevant to model v.(X) to be still transmitted, then the device will experience a delay in receiving model v.(X+1) and consequently the new training for the device will be delayed. Considering a scenario with large set of devices, impacting the delay with when they will start a newer training will impact the overall iteration time. The delay impact depends on how much data are buffered, on which layer to most of data to be transmitted is buffered, e.g., TCP requires an round trip time (RTT) for being sure that transmitted data have been received, and also on whether there is higher priority traffic in the network which will be then prioritized for transmission compared to model data, with consequent additional delay for sending “outdated” buffered data of previous version.

• From a communication perspective, this will involve inefficiencies in radio resource utilization as radio resources will be used to send data which are not relevant from an application logic point of view, thus, data which will be discarded by the application, instead of sending other data more useful. The radio resource inefficiency depends on how much data are buffered, but also on radio conditions of the devices as there could be multiple re-transmissions triggered by MAC/RLC/TCP layers - thus, more radio resources needed - to recover lost data, which will be discarded by the application. Finally, the impact of radio resource inefficiencies is more severe when large set of devices are used for training, more radio resources needed, when radio resources are limited or in situation of congestion, radio resource are limited but some of them are used for transmitting data that application will discard, and in scenarios where learning traffic has higher priority in the network as the network will prioritize radio resources for data, which will be discarded by the application, from learning devices at the expenses of other lower-priority traffic. Moreover, as radio resource usage increases, for transmitting data not anymore necessary to application, this may cause additional interference to other cells thereby resulting in degraded network performance.

• From a device perspective, this will involve inefficiencies in the power-supply management as devices will consume energy to transmit/receive data which are not relevant from an application logic point of view, thus, data which will be discarded by the application. This may be important for aspects such as overall energy consumption optimization and for internet of things (loT) applications where the battery lifetime is an important requirement. As a consequence, an enlargement of the discontinuous transmission (DTX) periodicity may be needed, and this may be detrimental from the latency viewpoint.

Although the problem depicted in Fig. 2 can be easily mapped to a federated learning (FL) scenario due to a clear relationship to be maintained between upload and download of models, i.e., no need to transfer data for a certain version of a model if a newer version has been generated, the problem may be extended to other scenarios as well. For example, in wireless sensor networks scenarios, it may happen that an application sends data to lower layers but then recognizes that this data was not accurate enough, e.g., when a new round of calibration allows a sensor to produce better tuned data.

An object herein is therefore to provide a mechanism to handle data in an efficient manner in the communications network.

According to an aspect the object is achieved, according to embodiments herein, by providing a method performed by a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communication device receives at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The communication device removes the data from the buffer.

According to another aspect the object is achieved, according to embodiments herein, by providing a method performed by a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communication device generates, at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The communication device provides the indication to another layer being a lower layer relative to the layer.

It is furthermore provided herein a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the methods herein, as performed by the communication devices, respectively. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the methods herein, as performed by the communication devices, respectively.

According to yet another aspect the object is achieved, according to embodiments herein, by providing a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communication device is configured to receive at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The communication device is further configured to remove the data from the buffer.

According to still another aspect the object is achieved, according to embodiments herein, by providing a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communication device is configured to generate, at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The communication device is further configured to provide the indication to another layer being a lower layer relative to the layer.

According to still another aspect the object is achieved, according to embodiments herein, by providing a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network. The communication device is configured to generate, at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The communication device is further configured to provide the indication to another layer being a lower layer relative to the layer. The communication device is configured to remove, at the other layer, the data from the buffer.

Embodiments herein allow, for example, an application layer to send an indication to a transport layer to indicate that data not yet transmitted for a certain session or stream can be discarded. The transport layer removes the data from the buffer, and the reception of this indication may further trigger the transport layer to generate a message carrying the information that data not yet transmitted for the target stream can be discarded. The reception of this message by lower layers, for example, RAN layers, further allows lower layers to discard the relevant buffered data not yet transmitted.

Thus, an application may indicate to lower layers that buffered data for a specific application stream could be discarded and consequently this avoids that radio resources are being used to transmit data that will be discarded by a layer. Thus, embodiments herein handle data in an efficient manner in the communications network.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described in more detail in relation to the enclosed drawings, in which:

Fig. 1 shows a stack transmission overview according to prior art;

Fig. 2 shows a stack transmission overview according to prior art;

Fig. 3 shows a communications network according to embodiments herein;

Fig. 4 shows a combined signalling scheme and flow chart according to embodiments herein;

Fig. 5 is depicting a method performed by a communication device according to embodiments herein; Fig. 6 is depicting a method performed by a communication device according to embodiments herein;

Fig. 7 is depicting an example of federating learning according to prior art;

Fig. 8 is depicting an example of federating learning according to prior art;

Fig. 9 is depicting an example of federating learning according to prior art;

Fig. 10 is depicting an example of federating learning according to prior art;

Fig. 11 is depicting a schematic overview according to embodiments herein;

Fig. 12 shows a block diagram depicting the communication device according to embodiments herein;

Fig. 13 shows a block diagram depicting the communication device according to embodiments herein;

Fig. 14 shows a block diagram depicting the communication device according to embodiments herein;

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

Fig. 16 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

Fig. 17,18,19 and 20 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

Embodiments herein relate to communications networks in general. Fig. 3 is a schematic overview depicting a communications network 1. The communications network 1 comprises one or more access networks, such as RANs, and one or more CNs. The communications network 1 may use one or a number of different technologies. Embodiments herein relate to recent technology trends that are of particular interest in a New Radio (NR) context, however, embodiments are also applicable in further development of existing wireless communications systems such as e.g. WiFi, LTE, Wideband Code Division Multiple Access (WCDMA), or any packet handling network.

In the communications network 1 , one or more user equipments (UE) 10, for example, a wireless device such as a mobile station, a non-access point (non-AP) station (ST A), a STA and/or a wireless terminal, are communicating via e.g. one or more Access Networks (AN), e.g. radio access network (RAN), to one or more core networks (CN). It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communications terminal, user equipment, narrowband internet of things (NB-loT) device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station capable of communicating using radio communication with a radio network node within an area served by the radio network node.

The communications network 1 comprises one or more radio network nodes 12,13 providing radio coverage over a respective geographical area, a first service area 11 or first cell, of a first radio access technology (RAT), such as NR, LTE, or similar; or a second service area 14 or second cell, of a RAT, such as NR, LTE, or similar. The radio network node 12,13 may be a transmission and reception point such as an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP ST A), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within the area served by the radio network node depending e.g. on the first radio access technology and terminology used. The radio network node may be referred to as a serving radio network node wherein the service area may be referred to as a serving cell, and the serving network node communicates with the UE in form of DL transmissions to the UE and UL transmissions from the UE. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.

The communications network 1 comprises a network node 15 for, for example, handling application data, for example, node for creating an Artificial Intelligence (Al) model, controlling a federated learning model, or handling application data of different versions or models.

According to embodiments it is herein provided a communication device 100 comprising a protocol stack comprising a plurality of layers, to perform any of the methods described herein. The communication device 100 may be any node such as the network node 15, the radio network node 12 or the UE 10.

Embodiments herein relate to handle data related to updated applications or models such as application of different versions or updated models, in an efficient manner in that an indication is transmitted between layers to trigger emptying of a buffer of data related to data no longer relevant.

Embodiments have one or more of the following advantages: • From a communication perspective, embodiments herein may reduce inefficiencies of radio resource utilization, since data relevant to, for example, a previous model v.(X) buffered in various layers of the protocol stack is removed and this means that radio resources will be then used to send data relevant to application logic instead of being used to transmit data which will be discarded by the application, or to send other more useful data. Overall, as usage of radio resources for a device and network will be reduced, this allows to reduce other parameters such overall energy consumption, interference, etc.

• This solution can be applied to both downlink and uplink direction, i.e., application could trigger to clear un-transmitted buffered data at device and/or server side, while RAN layers at either device or network side could be informed to clear untransmitted data at their respective buffers. Embodiments herein may rely on a user-plane message exchange between upper layers such as transport layers and lower layers such as RAN layers, and consequently this solution avoids inter-layer interactions between system domain, such as application, transport, operating system, and RAN domain which are, overall, complex and in addition will not be suitable for realization in downlink direction as these domains may be split into different nodes, unless one would define a specific control-plane signalling which will require changes to several parts of the network.

Fig. 4 shows a combined flowchart and signalling scheme according to embodiments herein performed in the communication device 100 comprising a protocol stack comprising a plurality of layers.

Action 401 . A layer such as an application layer (A-L) may trigger a generation of the indication in the event of one or more of the following:

(i) a model with a newer version has been generated at the layer;

(ii) the application started to receive a model with a newer version;

(iii) information has been received which indicates that a model with a newer version has been generated;

(iv) information has been received which explicitly indicates to stop ongoing model transfer;

(v) the application has recognized that data previously generated should now be refreshed as previous data was not accurate enough or a new calibration has happened. Action 402. The application layer may first remove data related to the application present in its own one or more buffers.

Action 403. The application layer generates an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below a lower layer relative to the receiving layer, or transmitted to a receiving device.

Action 404. The application layer provides, for example, sends, the indication to a lower layer relative to the layer, such as a transport layer (T-L).

Action 405. The transport layer receives and removes data that have not been yet submitted to one or more layers below the transport layer from the buffer.

Action 406. The transport layer may then generate a data message constructed to carry information. The data message may be a packet with only a TCP header where source and destination ports are set to the values associated to a socket of the application, and wherein an “Options” field is set to a value which will be understood by lower layers as “clear un-transmitted buffered data”. In case of QUIC layer, the third layer may generate a packet with only a QUIC header where source/destination ports and CONNECTION ID are set to values associated to the socket of the application, and where some fields in the “common header” are set to a value, which will be understood by lower layers as “clear un-transmitted buffered data”. In another example, a newly defined header field indicating “clear un-transmitted buffered data” may be introduced in target protocols such as TCP, UDP, QUIC etc.

Action 407. The transport layer then sends the data message with the information to a lower layer relative to the transport layer, such as a RAN layer (RAN-L).

Action 408. The RAN layer receives the data message and removes data that have not been yet submitted to one or more layers below the RAN layer from the buffer.

Action 409. The RAN layer may further trigger an indication to other lower layers, relative to the RAN layer, to clear un-transmitted buffered data for the session. Focusing on RAN layers, a layer which receives packets from upper layers, e.g., the SDAP, receives the data message and checks whether it is a “clear un-transmitted buffered data” message, and triggers the indication. The RAN layer may send an indication directly to both PDCP and RLC, or to RRC. In this case, the SDAP may indicate to PDCP which radio bearer(s) the indication refers to and to the RLC which channel(s) the indication refers to. Additionally, or alternatively, the RAN layer may send an indication to the PDCP indicating which radio bearer(s) the indication refers to, the PDCP could then match the radio bearer(s) to corresponding the RLC channel(s) and sends an indication to the RLC associated to such channels. Additionally, or alternatively, the RAN layer may send an indication to the RRC indicating the reception of the “clear un-transmitted buffered data” message for a certain traffic, and the RRC then sends an indication to the PDCP and the RLC including information on the radio bearer(s) and/or channel(s) that are associated.

The method actions performed by the communication device 100 comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network 1 according to embodiments will now be described with reference to a flowchart depicted in Fig. 5. The actions do not have to be taken in the order stated below but may be taken in any suitable order. Actions performed in some embodiments are marked with dashed boxes.

Action 501. The communication device 100 receives at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The layer may be a transport layer; a RAN layer; a RRC layer; a SDAP layer; a PDCP layer; a RLC layer; or a MAC layer. The indication may be carried in a header field of a data message. The information may be a flag value, a specific field value, and/or an index value. When the layer is the transport layer, the transport layer receives an indication in a message from the application layer. When the layer is the RAN layer, the RAN layer receives a data message, being the indication, from the transport layer.

Action 502. The communication device 100 removes the data from the buffer. The communication device 100 may at the layer remove data associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer. For example, in case the layer is a RAN layer, remove data of a bearer associated to the application.

Action 503. The communication device 100 may, at the layer of the protocol stack, generate a data message constructed to carry information to its one or more lower layers, wherein the information indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or more lower layers or transmitted to a receiving device. The information may comprise the received indication or at least be based on the received indication. When the layer is the transport layer, the transport layer may generate a message carrying information based on the indication from the application layer. The information may be carried in a header field of the data message. The information may be a flag value, a specific field value, and/or an index value.

Action 504. The communication device 100 may send, from the layer of the protocol stack, the data message carrying the information to its one or more lower layers. The received indication may be associated with the information in the data message. Thus, the information may comprise the received indication or be based on the received indication. The communication device 100 may send a further indication directly to one or two lower layers relative to the layer, wherein the further indication indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or two lower layers or transmitted to a receiving device. The further indication may further indicate which radio bearer the further indication refers to and/or to which channel the further indication refers to. When the layer is a RRC layer, the communication device 100 may receive the indication indicating reception of the indication indicating to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, and may send the further indication to a PDCP layer; a RLC layer; and/or a MAC layer, including information on radio bearer and/or channel that are associated with the further indication. For example, that SDAP may receive a clear message, and the SDAP indicates to RRC this reception. Then RRC may indicate to PDCP or RLC to clear data. The received indication may comprise one or more indicators, and/or may comprise a real value, an index value, a flag value or similar.

For example, the indication may comprise an indicator to which application stream the indication refers to, the communication device 100 may then match the application stream to a corresponding radio bearer and/or to a corresponding channel based on the indicator.

The communication device 100 may then send an indication to a lower layer associated to the corresponding radio bearer and/or channel, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the lower layer, or transmitted to a receiving device. For example, the transport layer may send a “clear buffer message” to a RAN layer, then it is the RAN layer which understands and maps this message to a certain radio bearer, so, the “clear buffer message” doesn’t carry info on radio bearer but it is associated to an application stream. For example, the SDAP may send an indication directly to both PDCP and RLC. In this case, SDAP should indicate to PDCP which radio bearer(s) the indication refers to and to RLC which channel(s) the indication refers to. Alternatively, the SDAP could send an indication to PDCP indicating which radio bearer(s) the indication refers to, PDCP may then match the radio bearer(s) to corresponding RLC channel(s) and may send an indication to RLC associated to such channels. Alternatively, the SDAP could send an indication to RRC indicating the reception of the “clear untransmitted buffered data” message for a certain traffic, and the RRC may then send an indication to PDCP and RLC including information on the radio bearer(s) and /or channel(s) that are associated. Thus, the SDAP may send an indication directly to both PDCP and RLC, omitting the RRC, or to the RRC. Application or transport layer knows which application stream the indication refers to, but RAN layers know which radio bearer and/or channel the indication refers to. For example, a first RAN layer, e.g., SDAP, understands which radio bearer is mapped to a certain application stream. The indication may thus indicate which radio bearer the indication refers to. When the layer is SDAP or RRC receiving the indication indicating reception of the indication indicating to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, the SDAP or RRC provides the indication by sending the indication to PDCP, RLC and/or MAC including information on radio bearer and channel that are associated with the other indication. The indication may comprise one or more indicators. For example, the indication may comprise an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers.

The data message may be realized in different ways.

In a first example, considering TCP as target protocol, the TCP entity could generate a packet with only a TCP header where source and destination ports are set to the values associated to the socket of the application, and where the “Options” field is set to a value which will be understood by lower layers as “clear un-transmitted buffered data”. In this example, TCP will generate this packet and delivers it to e.g., IP, which will process it as a normal packet by e.g. adding IP source/destination addresses. Setting the value of “Options” field of the TCP header or of the common header of QUIC or of a new header field to identify “clear un-transmitted buffered data” may be done in different ways. One way could be that this value is standardized or agreed in e.g., a relevant industry forum. Another way could be that service and network provider agrees on a certain value associated to “clear un-transmitted buffered data”.

In a second example, considering QUIC as target protocol, the QUIC entity could generate a packet with only a QUIC header where source I destination ports and CONNECTION ID are set to the values associated to the socket of the application, and where some fields in the “common header” are set to a value e.g., the bit 0x80 set to 1 , which will be understood by lower layers as “clear un-transmitted buffered data”. In this example, QUIC will generate this packet and deliver it to e.g., IP, which will process it as a normal packet by, e.g., adding IP source/destination addresses.

In a third example, a newly defined header field indicating “clear un-transmitted buffered data” could be introduced in target protocols such as TCP, UDP, QUIC, etc.

The data message is associated to the same traffic e.g., source/destination port, source/destination IP address, protocol, etc., related to the target application.

The method actions performed by the communication device 100 comprising the protocol stack comprising a plurality of layers for handling data of an application in a communications network 1 according to embodiments will now be described with reference to a flowchart depicted in Fig. 6. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Actions performed in some embodiments are marked with dashed boxes.

Action 601 . The communication device 100 at the layer such as the application layer, may trigger the generation of the indication in the event of one or more of the following:

(i) a model with a newer version has been generated at the layer;

(ii) the application started to receive a model with a newer version;

(v) the application has recognized that data previously generated should now be refreshed as previous data was not accurate enough or a new calibration has happened.

Action 602. The communication device 100 generates at the layer of the protocol stack, the indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The layer may be an application layer. The indication may comprise a real value, an index value, a flag value or similar. Action 603. The communication device 100 may at the layer remove data associated to the stream of the application, in a local buffer which data have not been yet submitted to one or more layers below the layer.

Action 604. The communication device 100 provides the indication to another layer being a lower layer relative to the layer of the protocol stack. The indication provided may comprise an indication directly to one or two lower layers relative to the layer, and the indication further indicates which radio bearer the indication refers to and to which channel the indication refers to. The indication may comprise one or more indicators. For example, the indication may comprise an indicator to which radio bearer the indication refers to and an indicator to which channel the indication refers.

The indication sent to a lower layer to clear un-transmitted buffered data could be realized in different ways.

• In a first example, the indication could be realized via existing application programming interfaces (API) offered by the lower layer. Considering e.g., TCP as a lower layer, the application layer could use some sort of “READ” call that allows to read and consequently, remove data from the buffer of the socket associated to the application. In this case, the lower layer interprets the usage of the “READ” call to the transmission buffer as indication that the application is requiring to clear untransmitted buffered data.

• In another example, the indication could be realized via a newly defined API of the lower layer, e.g., a “CLEAR SOCKET” API which can be invoked by the application to request to clear un-transmitted buffered data for a certain socket. This API may be used by e.g. application layer as well as from other layers e.g., even access-related layers, depending on the implementation. The lower layer e.g., transport layer, may triggered by, e.g., the application layer, and may clear the data of the socket associated to the application which have not been delivered yet to its respective lower layer, whereas the other data which have been already delivered to lower layers and for which an ack is being awaited are kept guaranteeing the normal behavior of the protocol.

Application, i.e., application layer, may send the indication to the lower layer, like transport, since it would be not possible or too complex to send a message to a transport layer, for example there could be layers such as transport layer security (TLS) which encrypt most of the application message, consequently denying access to message content to transport layer. Another alternative would be to add new field in the application message which will be not encrypted, but this would mean changes to application message structure, which should be included e.g., in FTP/HTTP message, changes to behavior of intermediate layers, e.g., TLS, to avoid encryption of the new field, and to transport protocol to make sure that the new field is interpreted correctly. Overall, it is considered that the indication from application to transport layer could be a more suitable way, although the solution proposed here will work either way.

Embodiments herein may, for example, introduce that a layer of the protocol stack, e.g., a transport protocol:

• receives an indication from its upper layer, e.g., application layer, to clear the buffer from the data which have not been yet submitted to lower layers;

• clears the buffer for the stream or socket associated to the application;

• triggers the creation of a data message constructed to carry the information to its relevant lower layers that buffers relevant to the application traffic should be cleared from data which have not been yet submitted to lower layers.

Embodiments herein may further introduce that a layer in the radio access protocol stack, e.g.:

• a second layer, e.g., SDAP, checks messages received from upper layer, a first layer, which are relevant to a certain application traffic in order to identify whether the message carries the information that buffers relevant to the application traffic should be cleared from data which have not been yet submitted to lower layers; the second layer, e.g., SDAP, based on the reception of the message above, triggers the transmission of an indication to relevant lower layers, a third layer e.g., PDCP, RLC, MAC, to clear buffers for certain traffic, bearer and/or channels from data not yet submitted to lower layers;

• a third layer, e.g., PDCP, RLC, MAC, receives an indication to clear buffers for certain traffic, bearer and/or channels, from data not yet submitted to its respective lower layer, and performs the action accordingly.

FL is a scenario of reference for some embodiments herein. The FL paradigm is based on an iterative procedure where a server trains a global Artificial Intelligence (Al) model by aggregating local models coming from a set of devices. The approach of one FL iteration is shown in Fig. 7. First, the FL training server sends the current version of the global Al model to the FL devices. Upon receiving the model, the devices perform their local training and then send their updated version to the server. Finally, the server computes the new version of the model. There are two possible approaches of model aggregation: (a) based on the local model of all devices; (b) based on the local model of a subset of devices. Fig. 7 shows an example of federating learning, wherein the FL training server performs aggregation using inputs from all training devices. It should be noted that the FL training server may perform aggregation using inputs from a selected subset of training devices. The FL training server may utilize several criteria, download/upload capabilities, data availability, device capabilities, etc., to select the portion of users that will be involved in the communication within each iteration, where such criteria depend on FL / Al application logic. This is of interest because the usage of well-designed selection criteria might bring to reduction of the FL convergence time and FL training loss. Nevertheless, the benefits of device selection mechanism may be hard to achieve or reduced in practice due to the following reasons:

1) Approaches as in “Convergence Time Optimization for Federated Learning over Wireless Networks”, M. Chen, H. V. Poor, W. Saad, S. Cui, IEEE Transactions on Wireless Communications 20.4 (2020): 2457-2471 https://arxiv.org/abs/2001.07845, for example, consider that FL training server is aware of user channel conditions as well as radio resource utilization, so that the FL training server can select the portion of users with the most useful dataset which are also in good channel conditions, thus guaranteeing that more users can be scheduled given the available radio resources depending on the current load.

2) Approaches as in “Interplay between Distributed Al Workflow and URLLC”, M. Ganjalizadeh, H. S. Ghadikolaei, J. Haraldson, M. Petrova, Accepted to IEEE Global Communications Conference 2022, https://arxiv.org/abs/2208.01352, consider that FL training server can estimate upload/download time of FL devices precisely for each iteration so that the ones which minimize the iteration time can be selected. In real deployments, the knowledge of the communication-related user information may be inaccurate, e.g., application layer might have only a partial visibility or wrong interpretation of communication parameters compared to network, or missing, e.g., exposure of communication parameters by the network such as cell load or resource block (RB) utilization load is usually a sensitive information which is not always wanted to be exposed, and this may lead to longer iterations.

3) The knowledge of the communication-related user information increases the traffic overhead in the network, which could be either user- plane, if devices have to send such information to FL training server via user plane, or control-plane, if such information should be collected by the network and exposed to the FL training server. Although the overhead could be limited compared to model transfer size, especially for the case of user-plane, such “device-selection assistance information” should be sent independently from the model transfer to avoid that the FL training server will delay the device selection as, e.g., a model transfer is ongoing. This means that additional complexity would be needed, e.g., using different QoS flows or bearer for “device-selection assistance information” and model transfer to guarantee that they are independent.

4) Device selection based on communication-related user information has its highest benefits when there is some sort of alignment between the device selection mechanism and network behavior. For example, approaches as in “Convergence Time Optimization for Federated Learning over Wireless Networks”, M. Chen, H. V. Poor, W. Saad, S. Cui, IEEE Transactions on Wireless Communications 20.4 (2020): 2457-2471 https://arxiv.org/abs/2001.07845, consider that there is some sort of joint FL I network logic which consider how many resources would be available for the FL iteration and how to split radio resources among devices that should be selected for the FL iteration. This brings complexity for practical realization, as it would require that FL training server has knowledge of how, e.g., scheduling decisions are taken in the network, to know how resources are split among different traffic types and among FL traffic, so that the best device selection can be performed considering the network behavior.

A possible workaround to the above points is shown in Fig. 8. In this case, the server sends the model v.(X) to all or a group of devices, but then starts generating the new model when it has received the inputs from a subset of users. Hence, in this case, there is no need of selecting devices, even though the FL training server could select a subset of devices for sending the new model based on e.g. dataset availability, but, from a communication perspective, an approach like the one in “Interplay between Distributed Al Workflow and URLLC”, M. Ganjalizadeh, H. S. Ghadikolaei, J. Haraldson, M. Petrova, Accepted to IEEE Global Communications Conference 2022, https://arxiv.org/abs/2208.01352 could be seen as a practical way to have the shortest FL iteration time, as iteration time will depend on devices which are quicker in downloading, training and uploading their models, without requiring detailed network-related information such as radio resource utilization status, load, channel conditions, etc. Considering the case in Fig. 8, the upload of the model trained by device 3 and 4 is not used by the training server to perform model aggregation. This highlights that there are cases where model upload/download might not be synchronized in this scenario. These cases are shown in Fig. 9. In Fig. 9, device 3 starts receiving model v.(X+1) when it is still transmitting model v.(X). Hence, the upload of model v.(X) is no longer needed because the server has already computed the new version based on the inputs from the other devices, e.g., device 1 and 2 from Fig. 8. If this situation is not handled, device 3 may start uploading model v.(X+1) whereas the upload of model v.(X) is not yet completed, resulting in a waste of radio resources usage. In Fig. 10, the server starts downloading model v.(X+1) when the download of model v.(X) is not yet completed. Hence, the download of model v.(X) is not necessary anymore.

The high-level solution is shown in Fig. 11. The embodiments herein cover one or more of the following:

- Application layer triggers an indication to a lower layer to clear un-transmitted buffered data. Application layer triggers an indication to be sent to the lower layer, e.g., TCP, or QUIC, to clear buffered data for a certain session or stream which have not been transmitted yet. The lower layer, e.g., TCP or QUIC, which receives the indication from the application layer clears buffered data not yet transmitted which are associated to the session or stream of the application.

- A lower layer generates a message to clear un-transmitted buffered data for the session. The lower layer, e.g., TCP or QUIC, upon reception of the indication from the application layer, generates a message to be delivered to lower layers, relative the lower layer, which carries the information to clear buffered data associated to the session or stream.

- A lower layer that receives a message from one or more upper layers, triggers an indication to other lower layers to clear un-transmitted buffered data for the session. For example, a lower layer, such as SDAP, receives the message generated by the upper layers, e.g., TCP or QUIC, processes it and understands that it carries the information to clear buffered data associated to the session or stream. Consequently, this layer maps such message to the corresponding traffic, e.g., data bearer, and triggers an indication to other relevant lower layer(s) that buffered data for the identified traffic, e.g., data bearer, not yet transmitted should be discarded. In the FL perspective, embodiments herein may reduce the latency for a certain iteration. In a first example, if a device has still data to be transmitted relevant to model v.(X) while a newer model v.(X+1) should be transmitted instead, the solution according to embodiments herein will help to discard data relevant to model v.(X) buffered in various layers of the protocol stack and consequently the FL training server will experience shorter delay with receiving the newer trained model and thus model aggregation can be triggered sooner. In a second example, if an FL training server has a newer model v.(X+1) to send to a device but there are buffered data relevant to model v.(X) to be still transmitted, the solution according to embodiments herein will help to discard data relevant to model v.(X) buffered in various layers of the protocol stack, this speeds up the reception of model v.(X+1) and consequently the new training for the device will start sooner.

Embodiments herein allow an application layer to indicate to its lower layers that buffered data for that specific application stream could be discarded and consequently this avoids that radio resources are being used to transmit data that will be discarded by the application layer.

The application layer triggers the indication to a lower layer to clear un-transmitted buffered data. Different events may trigger the application layer to send the indication to lower layers, e.g.: (i) a model with a newer version has been generated at the application layer; (ii) the application layer started to receive a model with a newer version; (iii) an information has been received which indicates that a model with a newer version has been generated; (iv) an information has been received which explicitly indicates to stop ongoing model transfer; (v) the application layer has recognized that data previously generated should now be refreshed as previous data was not accurate enough or a new calibration has happened. The triggering events are left to application implementation based on application logic.

Application, i.e., application layer, may send an indication, e.g., a value or a flag, to the lower layer, like transport layer, since it would be not possible, or too complex, to send a message to a transport layer, for example there could be layers such as transport layer security (TLS) which encrypt most of the application message, consequently denying access to message content to transport layer. Another alternative would be to add new field in the application message which will be not encrypted, but this would mean changes to application message structure, which should be included e.g., in FTP/HTTP message, changes to behavior of intermediate layers, e.g., TLS, to avoid encryption of the new field, and to transport protocol to make sure that the new field is interpreted correctly. Overall, it is considered that the indication from application to transport layer could be a more suitable way, although the solution proposed here will work either way.

The lower layer generates a message to clear un-transmitted buffered data for the session. When the application layer invokes the indication to clear un-transmitted buffered data for the session at the lower layer, this triggers the lower layer e.g., transport layer, to generate a data message that carries the information to clear un-transmitted buffered data for the session to the other respective lower layers.

Thus, at the lower layer receiving the indication, such as a data message or indicator, from upper layers, this triggers an indication to other lower layers to clear un- transmitted buffered data for the session. Focusing on RAN layers, a layer which receives packets from upper layers, e.g., SDAP, receives the message and checks whether it is a “clear un-transmitted buffered data” message. To do so, it could for instance check the value of the “Options” field in the TCP header, or of the common header in QUIC, or overall of other header fields for TCP, UDP, QUIC, etc. Please note that a layer like SDAP is in charge of mapping user traffic to the corresponding radio bearer, by checking source/destination port, source/destination IP address, protocol, etc., so this layer will be able to identify to which radio bearer the “clear un-transmitted buffered data” message belongs to.

The SDAP may be configured via RRC or non-access stratum (NAS) signalling to check the presence and I or the values of header fields in TCP, UDP, QUIC etc. headers and it could be configured to check a specific field value which is associated to “clear un- transmitted buffered data”. The SDAP may be configured to perform this check only for the certain type of traffic, e.g., only for a certain 3-tuple or 5-tuple the SDAP will check specific header fields in TCP, UDP, QUIC etc. headers.

After understanding that the received message is “clear un-transmitted buffered data” and which traffic, radio bearer the message refers to, a RAN layer e.g., SDAP triggers an indication to other lower layers e.g., PDCP, RLC, to clear un-transmitted buffered data for the identified traffic. This could be realized in several ways, considering as example that SDAP is the layer which triggers the indication, and that the indication should reach PDCP and RLC:

• In a first realization, SDAP may send an indication directly to both PDCP and RLC. In this case, SDAP should indicate to PDCP which radio bearer(s) the indication refers to and to RLC which channel(s) the indication refers to.

• In a second realization, SDAP may send an indication to PDCP indicating which radio bearer(s) the indication refers to, PDCP may then match the radio bearer(s) to corresponding RLC channel(s) and sends an indication to the RLC associated to such channels.

• In a third realization, SDAP may send an indication to RRC indicating the reception of the “clear un-transmitted buffered data” message for a certain traffic, and the RRC then sends an indication to PDCP and RLC including information on the radio bearer(s) and/or channel(s) that are associated.

At the reception of the indication, the RAN layer(s), e.g., PDCP and/or RLC, clears the data of the traffic, bearer, channel, etc., associated to the application which have not been delivered yet to its respective lower layer, whereas the other data which have been already delivered to lower layers and for which an ack is being awaited are kept guaranteeing the normal behavior of the protocol.

Fig. 12 is a block diagram depicting embodiments of the communication device 100 comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network according to embodiments herein.

The communication device 100 may comprise processing circuitry 1201 , e.g., one or more processors, configured to perform the methods herein.

The communication device 100 and/or the processing circuitry 1201 is configured to receive at the layer of the protocol stack, the indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device. The received indication may be associated with the information in the data message. The layer may be: a transport layer; a RAN layer; an RRC layer; a SDAP layer; a PDCP layer; an RLC layer; or a MAC layer.

The communication device 100, and/or the processing circuitry 1201 is configured to remove the data from the buffer.

The communication device 100 and/or the processing circuitry 1201 may be configured to generate at the layer of the protocol stack, the data message constructed to carry information to its one or more lower layers, wherein the information indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the one or more lower layers or transmitted to a receiving device.

The communication device 100 and/or the processing circuitry 1201 may further be configured to send the data message carrying the information to the one or more lower layers or to the receiving device. The information may be carried in the header field of the data message and/or be a specific field value.

The communication device 100 and/or the processing circuitry 1201 may be configured to send the further indication directly to one or two lower layers relative to the layer, wherein the further indication indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the one or two lower layers or transmitted to a receiving device. The further indication may further indicate which radio bearer the further indication refers to and/or to which channel the further indication refers to.

The communication device 100 and/or the processing circuitry 1201 may be configured to, when the layer is a RRC layer, receive the indication indicating reception of the indication indicating to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, and to send the further indication by sending the further indication to a PDCP layer; a RLC layer; and/or a MAC layer, including information on radio bearer and/or channel that are associated with the further indication.

The received indication may comprise an indicator to which application stream the indication refers to, and the communication device 100 and/or the processing circuitry 1201 may be configured to match the application stream to a corresponding radio bearer and/or to a corresponding channel based on the indicator; and to send an indication to a lower layer associated to the corresponding radio bearer or channel, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the lower layer, or transmitted to a receiving device.

The received indication may comprise an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers.

The communication device 100 may comprise a memory 1205. The memory 1205 comprises one or more units to be used to store data on, such as data packets, subscription data, mapping, indications, indicators, data messages, models, data, parameters, mobility events, measurements, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the communication device 100 may comprise a communication interface 1206 comprising such as a transmitter, a receiver, a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the communication device 100 are respectively implemented by means of e.g., a computer program product 1207 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. The computer program product 1207 may be stored on a computer-readable storage medium 1208, e.g., a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1208, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a communication device 100 for handling communication in a communications network, wherein the communication device 100 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said communication device 100 is operative to perform any of the methods herein.

Fig. 13 is a block diagram depicting embodiments of the communication device 100 comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network according to embodiments herein.

The communication device 100 may comprise processing circuitry 1301 , e.g., one or more processors, configured to perform the methods herein.

The communication device 100 and/or the processing circuitry 1301 is configured to generate at the layer of the protocol stack, the indication. The indication indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to the receiving device. The layer may be an application layer.

The communication device 100 and/or the processing circuitry 1301 is configured to provide the indication to another layer being a lower layer relative to the layer. The communication device 100 and/or the processing circuitry 1301 may be configured to provide the indication directly to one or two lower layers relative to the layer, and wherein the indication further indicates which radio bearer the indication refers to and/or to which channel the indication refers to.

The communication device 100 and/or the processing circuitry 1301 may be configured to trigger generation of the indication in the event of one or more of the following: (i) a model with a newer version has been generated at the layer;

(ii) the application started to receive a model with a newer version;

The indication may comprise an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers.

The communication device 100 and/or the processing circuitry 1301 may be configured to remove data associated to the stream of the application, in the local buffer which data have not been yet submitted to one or more layers below the layer.

The communication device 100 may comprise a memory 1305. The memory 1305 comprises one or more units to be used to store data on, such as data packets, subscription data, mapping, indications, models, data, parameters, indicators, data messages, networks, mobility events, measurements, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the communication device 100 may comprise a communication interface 1306 comprising such as a transmitter, a receiver, a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the communication device 100 are respectively implemented by means of e.g., a computer program product 1307 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. The computer program product 1307 may be stored on a computer-readable storage medium 1308, e.g., a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1308, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a communication device 100 for handling communication in a communications network, wherein the communication device 100 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said communication device 100 is operative to perform any of the methods herein.

Fig. 14 is a block diagram depicting embodiments of the communication device 100 comprising the protocol stack comprising the plurality of layers for handling data of an application in a communications network according to embodiments herein.

The communication device 100 may comprise processing circuitry 1401 , e.g., one or more processors, configured to perform the methods herein.

The communication device 100 and/or the processing circuitry 1401 is configured to generate at a first layer of the protocol stack, the indication. The indication indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the receiving layer, or transmitted to a receiving device. The first layer may be an application layer. The communication device 100, and/or the processing circuitry 1401 is configured to remove the data from the buffer at the first layer.

The communication device 100 and/or the processing circuitry 1401 is configured to provide the indication to a second layer being a lower layer relative to the first layer. The communication device 100 and/or the processing circuitry 1401 may be configured to provide the indication directly to one or two lower layers relative to the first layer, and wherein the indication further indicates which radio bearer the indication refers to and/or to which channel the indication refers to. The second layer may be: a transport layer or a RAN layer.

The communication device 100 and/or the processing circuitry 1401 may be configured to generate at the second layer of the protocol stack, the data message constructed to carry information to its one or more lower layers, wherein the information indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the one or more lower layers or transmitted to the receiving device.

The communication device 100 and/or the processing circuitry 1401 may be configured to remove at the second layer, data associated to the stream of the application, in a local buffer which data have not been yet submitted to one or more layers below the second layer. The communication device 100 and/or the processing circuitry 1401 may further be configured to send the data message carrying the information to a third layer or to a receiving device. The information may be carried in the header field of the data message and/or be a specific field value.

The communication device 100 and/or the processing circuitry 1401 may be configured to send the further indication directly to one or two lower layers, wherein the further indication indicates to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the one or two lower layers or transmitted to a receiving device. The further indication may further indicate which radio bearer the further indication refers to and/or to which channel the further indication refers to.

The communication device 100 and/or the processing circuitry 1401 may be configured to remove at the one or more lower layers, data associated to the stream of the application, in a local buffer which data have not been yet submitted to one or more layers below the one or more lower layers layer.

Thus, the communication device 100 and/or the processing circuitry 1401 may be configured to: generate, at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; provide the indication to another layer being a lower layer relative to the layer; and to remove, at the other layer, the data from the buffer.

The communication device 100 may comprise a memory 1405. The memory 1405 comprises one or more units to be used to store data on, such as data packets, subscription data, mapping, indications, indicators, data messages, models, data, parameters, networks, mobility events, measurements, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the communication device 100 may comprise a communication interface 1406 comprising such as a transmitter, a receiver, a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the communication device 100 are respectively implemented by means of e.g., a computer program product 1407 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. The computer program product 1407 may be stored on a computer-readable storage medium 1408, e.g., a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1408, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the communication device 100. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium.

Thus, embodiments herein may disclose a communication device 100 for handling communication in a communications network, wherein the communication device 100 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said communication device 100 is operative to perform any of the methods herein.

In some embodiments a more general term “network node” is used and it can correspond to any type of radio-network node or any network node, which communicates with a wireless device and/or with another network node. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc.

In some embodiments the non-limiting term wireless device or user equipment (UE) is used and it refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc.

Embodiments are applicable to any RAT or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

As will be readily understood by those familiar with communications design, that functions means or circuits may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a wireless device or network node, for example.

Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term “processor” or “controller” as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware and/or program or application data. Other hardware, conventional and/or custom, may also be included. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure. With reference to Fig. 15, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211 , such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the network node 12 herein, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first UE 3291 , being an example of the UE 10, located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 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 3212.

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

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

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 16. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 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 3310 further comprises software 3311 , which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig.16) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig.16) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, 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 3320 further has software 3321 stored internally or accessible via an external connection.

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

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 16 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291 , 3292 of Fig. 15, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 16 and independently, the surrounding network topology may be that of Fig. 15.

In Fig. 16, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the user equipment 3330 via the base station 3320, 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 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 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 3370 between the UE 3330 and the base station 3320 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 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the performance since less irrelevant data is processed and thereby provide benefits such as improved efficiency and may lead to better performance such as better responsiveness, and better battery lifetime of the UE.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 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 3311 , 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. 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 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311 , 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 17 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, 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 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 18 will be included in this section. In a first step 3510 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 3520, 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 3530, the UE receives the user data carried in the transmission.

Fig. 19 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 19 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step

in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 20 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 20 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.

It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings. Instead, the embodiments herein are limited only by the following claims and their legal equivalents.

Claims

1 . A method performed by a communication device comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network, the method comprising receiving (501) at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; and removing (502) the data from the buffer.

2. The method according to claim 1 , further comprising

- generating (503) at the layer of the protocol stack, a data message constructed to carry information to its one or more lower layers, wherein the information indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or more lower layers or transmitted to the receiving device; and

- sending (504) the data message carrying the information to the one or more lower layers or to the receiving device.

3. The method according to the claim 2, wherein the information is carried in a header field of the data message and/or is a specific field value.

4. The method according to any of the claims 2-3, wherein received indication is associated with the information in the data message.

5. The method according to claim 1 , further comprising sending a further indication directly to one or two lower layers relative to the layer, wherein the further indication indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or two lower layers or transmitted to a receiving device, and wherein the further indication further indicates which radio bearer the further indication refers to and/or to which channel the further indication refers to. The method according to claims 5, further comprising, when the layer is a radio resource control, RRC, layer, receiving the indication indicating reception of the indication indicating to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, and sending the further indication comprises sending the further indication to a Packet Data Convergence Protocol, PDCP, layer; a radio link control, RLC, layer; and/or a Medium Access Control, MAC, layer, including information on radio bearer and/or channel that are associated with the further indication. The method according to any of the claims 1-6, wherein the received indication comprises an indicator to which application stream the indication refers to, and the method further comprises matching the application stream to a corresponding radio bearer and/or to a corresponding channel based on the indicator; and

- sending an indication to a lower layer associated to the corresponding radio bearer or channel, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the lower layer, or transmitted to a receiving device. The method according to any of the claims 1-7, wherein the layer is: a transport layer; a radio access network, RAN, layer; a radio resource control, RRC, layer; a Service Data Adaption Protocol, SDAP, layer; a Packet Data Convergence Protocol, PDCP, layer; a radio link control, RLC, layer; or a Medium Access Control, MAC, layer. The method according to any of the claims 1-8, wherein the received indication comprises an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers. A method performed by a communication device (100) comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network, the method comprising

- generating (602) at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; and providing (604) the indication to another layer being a lower layer relative to the layer. The method according to claim 10, wherein providing the indication comprises providing the indication directly to one or two lower layers relative to the layer, and wherein the indication further indicates which radio bearer the indication refers to and/or to which channel the indication refers to. The method according to any of the claims 10-11 , wherein the layer is an application layer. The method according to any of the claims 10-12, further comprising

- triggering (601) the generation of the indication in the event of one or more of the following:

(i) a model with a newer version has been generated at the layer;

(ii) the application started to receive a model with a newer version;

(v) the application has recognized that data previously generated should now be refreshed as previous data was not accurate enough or a new calibration has happened. The method according to any of the claims 10-13, wherein the indication comprises an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers. The method according to any of the claims 10-14, further comprising removing (603) data associated to the stream of the application, in a local buffer which data have not been yet submitted to one or more layers below the layer.

16. A communication device (100) comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network, wherein the communication device is configured to receive at a layer of the protocol stack, an indication from another layer being an upper layer relative to the layer, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; and remove the data from the buffer.

17. The communication device (100) according to claim 16, wherein the communication device is configured to generate at the layer of the protocol stack, a data message constructed to carry information to its one or more lower layers, wherein the information indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or more lower layers or transmitted to the receiving device; and send the data message carrying the information to the one or more lower layers or to the receiving device.

18. The communication device (100) according to the claim 17, wherein the information is carried in a header field of the data message and/or is a specific field value.

19. The communication device (100) according to any of the claims 16-17, wherein received indication is associated with the information in the data message.

20. The communication device (100) according to claim 16, wherein the communication device is configured to send a further indication directly to one or two lower layers relative to the layer, wherein the further indication indicates to clear data, associated to the stream of the application, in a buffer which data have not been yet submitted to one or more layers below the one or two lower layers or transmitted to a receiving device, and wherein the further indication further indicates which radio bearer the further indication refers to and/or to which channel the further indication refers to. The communication device (100) according to claims 20, wherein the communication device is further configured to, when the layer is a radio resource control, RRC, layer, receive the indication indicating reception of the indication indicating to clear data, associated to the stream of the application, in the buffer which data have not been yet submitted to one or more layers below the layer, and to send the further indication by sending the further indication to a Packet Data Convergence Protocol, PDCP, layer; a radio link control, RLC, layer; and/or a Medium Access Control, MAC, layer, including information on radio bearer and/or channel that are associated with the further indication. The communication device (100) according to any of the claims 16-21 , wherein the received indication comprises an indicator to which application stream the indication refers to, and the communication device is further configured to match the application stream to a corresponding radio bearer and/or to a corresponding channel based on the indicator; and send an indication to a lower layer associated to the corresponding radio bearer or channel, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the lower layer, or transmitted to a receiving device. The communication device (100) according to any of the claims 16-22, wherein the layer is: a transport layer; a radio access network, RAN, layer; a radio resource control, RRC, layer; a Service Data Adaption Protocol, SDAP, layer; a Packet Data Convergence Protocol, PDCP, layer; a radio link control, RLC, layer; or a Medium Access Control, MAC, layer. The communication device (100) according to any of the claims 16-23, wherein the received indication comprises an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers. A communication device (100) comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network, wherein the communication device is configured to generate at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; and provide the indication to another layer being a lower layer relative to the layer.

26. The communication device (100) according to claim 25, wherein the communications device is configured to provide the indication directly to one or two lower layers relative to the layer, and wherein the indication further indicates which radio bearer the indication refers to and/or to which channel the indication refers to.

27. The communication device (100) according to any of the claims 25-26, wherein the layer is an application layer.

28. The communication device (100) according to any of the claims 25-27, wherein the communication device is configured to trigger generation of the indication in the event of one or more of the following:

(vi) a model with a newer version has been generated at the layer;

(vii) the application started to receive a model with a newer version;

(viii) information has been received which indicates that a model with a newer version has been generated;

(ix) information has been received which explicitly indicates to stop ongoing model transfer;

(x) the application has recognized that data previously generated should now be refreshed as previous data was not accurate enough or a new calibration has happened.

29. The communication device (100) according to any of the claims 25-28, wherein the indication comprises an indicator to which radio bearer the indication refers to and/or an indicator to which channel the indication refers.

30. The communication device (100) according to any of the claims 25-29, wherein the communication device is further configured to remove data associated to the stream of the application, in a local buffer which data have not been yet submitted to one or more layers below the layer. A communication device (100) comprising a protocol stack comprising a plurality of layers for handling data of an application in a communications network., wherein the communication device is configured to: generate, at a layer of a protocol stack, an indication, wherein the indication indicates to clear data, associated to a stream of the application, in a buffer which data have not been yet submitted to one or more layers below the layer, or transmitted to a receiving device; provide the indication to another layer being a lower layer relative to the layer; and to remove, at the other layer, the data from the buffer. A computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-15, as performed by a communication device. A computer-readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-15, as performed by a communication device.