Patent Description:
A critical requirement of 3GPP <NUM> new radio (NR) is the support for ultra reliable low latency communication (URLLC) services, where latency expresses the time required for transmitting a message through the network. The requirement in Rel-<NUM> for URLLC has been set to a latency of <NUM>, one way over the radio access network, combined with a packet error rate (PER) of 10e-<NUM>. For Rel-<NUM> it is expected that the requirements will be set even tougher.

An application will request certain QoS of the <NUM> network and may have multiple data streams, each with an individual QoS setting. If the requested levels of QoS are accepted by the <NUM> network, the <NUM> network will try to fulfil its QoS obligations towards the application over time. In wireless networks, there are several factors affecting the QoS that can be achieved in reality such as e.g. unpredictable movement of the client device or movement from other objects causing blocking of radio signals. Hence, there will be situations where the negotiated QoS will not be met.

For future application types, targeted by NR, this fact may be critical. Example of areas for such URLLC traffic can be within the road traffic control and management, production industry or health care, with applications such as remote driving, platooning, factory automation or remote surgery. These are typical examples of applications that do not only require demanded QoS but also represent cases where an instantaneous failure or rapid degradation of the actually delivered QoS from the radio access network can have dire consequences. This fact has been lifted by organisations, such as 5GAA and <NUM>-ACIA, setting the input requirements for <NUM> focusing on vehicle and industrial use cases, respectively, where prediction of delivered QoS is seen as an important area.

Packet duplication, which is one way to increase the reliability, was introduced in Rel-<NUM> to facilitate URLLC services. In Rel-<NUM>, packet duplication is configured with either carrier aggregation (CA) or dual connectivity (DC). In future releases, packet duplication with DC and CA will also be supported. For the duplication case the network ensures using different component carriers for the respective transmission of different radio link control entities with logical channel mapping restrictions.

Further, <CIT> refers to a method performed by a user equipment in a communication system in which the user equipment communicates data with a base station using at least one data radio bearer (DRB). The data is communicated using a plurality of data flows that are mapped to a single DRB. Each data flow is configured to have a respective set of quality of service (QoS) characteristics specific to that data flow. The user equipment measures quality of experience (QoE) parameters for the data flows and reports QoE information to the base station based on the measurement of the QoE parameters.

The QoS monitoring configuration can in this disclosure comprise e.g. number of independent radio links, a set of rules, a timer or a time window.

The feature notification control has been introduced to allow the core network (CN) to be notified by the radio access network (RAN) when a negotiated QoS cannot be met. Notification control is applicable for guaranteed bit rate flows. The core network requests the radio access network to notify the core network, during a packet data unit (PDU) session life span, when a negotiated QoS cannot be met. This feature is intended for applications which can adjust to changes in QoS, e.g. video streaming where the video codec bit rate may be adjusted dynamically. For example, when an application in the data network is notified that a negotiated QoS cannot be met it can adjust its codec rate and the radio access network may then, if needed, reconfigure the data radio bearer to the client device to better suit the new bit rate.

In the lower layers, the client device monitors the radio link connection. Radio link failure (RLF) is declared in the client device after a certain preconfigured number of detected out-of-synchronizations (3GPP TS <NUM>, section <NUM>). An out-of-synchronization is defined as a certain number of radio link measurements over a time period, typically <NUM>-<NUM>, where the signal-to-interference and noise ratio (SINR) is too low to achieve sufficient downlink control channel decoding performance. At RLF, upper layers in the client device report "No-Service" to applications, while lower layers try to restore the radio link or search for a new radio link.

Notification control is based in the core network with assistance from the radio access network. Interaction with the application in the client device would go via the core network to the corresponding application in the data network and then to the application in the client device. This is a slow mechanism and it further requires a working link to the client device, if the application in the data network would like to communicate with the application in client device upon a reported notification control. Hence, for URLLC use cases, this notification is too slow.

The RLF procedure is performed in the client device but it is also a slow mechanism. The purpose is to declare the radio link as lost and not to detect QoS problems early. The RLF procedure is suitable for enhanced mobile broadband (eMBB) type of applications but for sensitive URLLC applications the RLF procedure is too slow, typically in the order of <NUM> instead of single ms. Hence, the RLF procedure does not allow the application to take any precautionary actions. Setting the parameters for RLF to enable the client device to declare RLF at an earlier time may lead to unnecessary amount of radio link recovery procedures and increase the time spent with no service.

Hence, the inventors realize that there is a need for a method for declaring problems with the connection serving an application with fast response time compared to current conventional methods.

<FIG> shows a client device <NUM> according to an embodiment of the invention. In the embodiment shown in <FIG>, the client device <NUM> comprises a processor <NUM>, a transceiver <NUM> and a memory <NUM>. The processor <NUM> is coupled to the transceiver <NUM> and the memory <NUM> by communication means <NUM> known in the art. The client device <NUM> further comprises an antenna or antenna array <NUM> coupled to the transceiver <NUM>, which means that the client device <NUM> is configured for wireless communications in a wireless communication system.

That the client device <NUM> is configured to perform certain actions can in this disclosure be understood to mean that the client device <NUM> comprises suitable means, such as e.g. the processor <NUM> and the transceiver <NUM>, configured to perform said actions.

According to embodiments of the invention the client device <NUM> is configured to obtain a QoS monitoring configuration associated with an application and monitor for a QoS non-fulfillment in one or more radio links serving the application based on the QoS monitoring configuration. The client device <NUM> is further configured to provide a QoS non-fulfillment indication <NUM> to the application upon detection of a QoS non-fulfillment of one or more QoS requirements obtained from the QoS monitoring configuration.

<FIG> shows a flow chart of a corresponding method <NUM> which may be executed in a client device <NUM>, such as the one shown in <FIG>. The method <NUM> comprises obtaining <NUM> a QoS monitoring configuration associated with an application and monitoring <NUM> for a QoS non-fulfillment in one or more radio links serving the application based on the QoS monitoring configuration. The method <NUM> further comprises providing <NUM> a QoS non-fulfillment indication <NUM> to the application upon detection of a QoS non-fulfillment of one or more QoS requirements obtained from the QoS monitoring configuration.

<FIG> shows a network node <NUM> according to an embodiment of the invention. In the embodiment shown in <FIG>, the network node <NUM> comprises a processor <NUM>, a transceiver <NUM> and a memory <NUM>. The processor <NUM> is coupled to the transceiver <NUM> and the memory <NUM> by communication means <NUM> known in the art. The network node <NUM> may be configured for both wireless and wired communications in wireless and wired communication systems, respectively. The wireless communication capability is provided with an antenna or antenna array <NUM> coupled to the transceiver <NUM>, while the wired communication capability is provided with a wired communication interface <NUM> coupled to the transceiver <NUM>.

That the network node <NUM> is configured to perform certain actions can in this disclosure be understood to mean that the network node <NUM> comprises suitable means, such as e.g. the processor <NUM> and the transceiver <NUM>, configured to perform said actions.

According to the invention the network node <NUM> is configured to obtain a QoS monitoring activation request <NUM> associated with an application from a client device <NUM>. The network node <NUM> is further configured to determine at least one part of a QoS monitoring configuration based on the QoS monitoring activation request <NUM> and transmit the QoS monitoring configuration <NUM> to the client device <NUM>.

<FIG> shows a flow chart of a corresponding method <NUM> which may be executed in a network node <NUM>, such as the one shown in <FIG>. The method <NUM> comprises obtaining <NUM> a QoS monitoring activation request <NUM> associated with an application from a client device <NUM>. The method <NUM> further comprises determining <NUM> at least one part of a QoS monitoring configuration based on the QoS monitoring activation request <NUM> and transmitting <NUM> the QoS monitoring configuration <NUM> to the client device <NUM>.

<FIG> shows a wireless communication system <NUM> according to an embodiment of the invention. The wireless communication system <NUM> comprises a client device <NUM>, in this embodiment denoted a first client device <NUM>, a second client device <NUM>', and a network node <NUM> configured to operate in the wireless communication system <NUM>. In the embodiment shown in <FIG>, the network node <NUM> can be a network node <NUM> in the core network and/or a network access node <NUM> in the radio access network. In the wireless communication system <NUM>, one or more downlink and/or uplink radio links 510a, 510b,. , 510n are established between the network access node <NUM> and the first client device <NUM> to serve an application in the first client device <NUM>. The application in the first client device <NUM> may be communicating with a corresponding application in a data network (not shown in <FIG>) connected to the network node <NUM>. The radio links 510a, 510b,. , 510n are established to fulfil a certain QoS requested by the application. Alternatively or in addition, one or more radio links 510a', 510b',. , 510n' may be established between the first client device <NUM> and the second client device <NUM>' to serve the application in the first client device <NUM>. The one or more radio links 510a', 510b',. , 510n' may e.g. be NR sidelinks (SL), sometimes referred to as PC5 interfaces.

According to embodiments of the invention a solution for providing a QoS non-fulfillment indication to the application in the client device <NUM> is introduced. The QoS non-fulfillment indication is a low latency indication that can give the application an early warning about QoS problems on the radio links 510a, 510b,. , 510n, 510a', 510b',. , 510n' used by the application. The low latency of the QoS non-fulfillment indication makes it suitable for future applications types targeted for <NUM>, e.g. applications where failure to meet QoS can have dire consequences to the client device <NUM> hosting the application or other client devices in its proximity. The QoS non-fulfillment indication can be used to trigger, autonomously in the client device <NUM>, a pre-programed behaviour in the application. Examples of such pre-programmed behaviour in the application is to take precautionary actions and/or enter into a "safe-mode".

Practical examples of such "safe-mode" in the vehicle-to-anything (V2X) area could be to decrease the speed and increase the distance between vehicles. For factory automation an actor, such as a robot, may simply halt its current activity. A drone may hover or return to a predefined location.

Consequently, the introduction of the QoS non-fulfillment indication according to the invention may play a vital role as a safety mechanism for future <NUM> applications, as a tool to prevent potential dire issues that could be caused by an instantaneous QoS degradation.

The invention introduces a solution for activation and configuration of the QoS non-fulfillment indication and monitoring and filtering of QoS indications from multiple violation detection sources, as well as methods in respective layer for routing of QoS indications and the QoS non-fulfillment indication. The invention further introduces reporting of the QoS non-fulfillment indication to the network and give examples of actions taken by the application in the case of a QoS non-fulfillment indication.

<FIG> shows a flow chart of a method <NUM> for monitoring for QoS non-fulfillment according to embodiments of the invention. In step <NUM>, the client device <NUM> obtains the QoS monitoring configuration associated with the application. The QoS monitoring configuration indicates at least one of: a QoS monitoring rule, information of downlink radio links serving the application, a downlink timer associated with the downlink radio links, information of uplink radio links serving the application, an uplink timer associated with the uplink radio links, and a QoS threshold value. Information of downlink and/or uplink radio links serving the application may indicate the number of radio links in downlink and/or uplink, and an identifier/tag or rule of identification of each radio link. The QoS monitoring configuration provides the client device <NUM> with information to configure the monitoring for QoS non-fulfillments for the radio links serving the application and to provide QoS non-fulfillment indications upon detection of a QoS non-fulfillment of one or more QoS requirements.

The client device <NUM> may obtain the QoS monitoring configuration in different ways. The client device <NUM> may in embodiments obtain the QoS monitoring configuration based on information received from the network node <NUM> and/or based on a predefined rule. Thus, the client device <NUM> may receive at least one part of the QoS monitoring configuration from the network node <NUM>. Furthermore, the client device <NUM> may derive at least one part of the QoS monitoring configuration from a predefined rule. Any combination of these two options is possible. Hence, the client device <NUM> may in embodiments receive the full QoS monitoring configuration from the network node <NUM>, derive the full QoS monitoring configuration from the predefined rule, or receive one part of the QoS monitoring configuration from the network node <NUM> and derive another part of the QoS monitoring configuration from the predefined rule. Any part of the QoS monitoring configuration received from the network node <NUM> may be received based on a request from the client device <NUM>, as described below with reference to <FIG>. Furthermore, when the client device <NUM> derives at least one part of the QoS monitoring configuration from a predefined rule, the client device <NUM> may use the predefined rule together with QoS information associated with the application. In embodiments, the client device <NUM> may hence derive at least one part of the QoS monitoring configuration from a predefined rule and in dependence on one or more characteristics of QoS flows or IP packet flows associated with the application, wherein the one or more characteristics are at least one of <NUM> QoS identifier, QoS flow identifier, resource type, packet error rate, packet delay budget, survival time, and jitter. The resource type indicates whether a QoS flow is of the type guaranteed bit rate (GBR), delay-critical GBR, or non-GBR flow. The definition of packet error rate and packet delay budget are different for GBR and delay-critical GBR resource types. Furthermore, the survival time can be the time period that an application consuming a communication service may continue without an anticipated message.

Based on the QoS monitoring configuration obtained in step <NUM>, the client device <NUM> monitors for a QoS non-fulfillment in one or more radio links serving the application in step <NUM>. That the monitoring in step <NUM> is based on the QoS monitoring configuration can e.g. mean that the client device <NUM> monitors radio links identified from the QoS monitoring configuration against one or more QoS requirements obtained from the QoS monitoring configuration. The QoS requirement may be any of error rate or latency. The error rate may be a block error rate (BLER) or a packet error rate (PER). The error rate may further be expressed as an actual error rate obtained after an actual transmission of data packets or a hypothetical error rate estimated based on measured reference signals, i.e. without an actual transmission of data packets. The latency may be expressed as a timer value derived from the packet delay budget, where the packet delay budget defines an upper bound for the time that a packet may be delayed between the client device and the user plane function that terminates the N6 interface. The latency may e.g. represent a portion of the packet delay budget.

In step <NUM>, the client device <NUM> checks whether a QoS non-fulfillment of one or more QoS requirements obtained from the QoS monitoring configuration has been detected. Upon detection of a QoS non-fulfillment of one or more QoS requirements in step <NUM>, the client device <NUM> provides/sends a QoS non-fulfillment indication <NUM> to the application in step <NUM>. If no QoS non-fulfillment is detected in step <NUM>, the client device <NUM> continuous to monitor for a QoS non-fulfillment in the one or more radio links serving the application in step <NUM>.

The detection of a QoS non-fulfillment in step <NUM> may comprise at least one of detect a QoS non-fulfillment in the downlink if at least one downlink radio link serving the application is indicated as not fulfilling a QoS requirement; and detect a QoS non-fulfillment in the uplink if at least one uplink radio link serving the application is indicated as not fulfilling a QoS requirement. At least one radio link, downlink or uplink, can herein be understood to mean a subset of all the radio links serving the application, where the subset can comprise one or more, up to all, of the radio links serving the application. In embodiments, the detection of a QoS non-fulfillment in step <NUM> may further consider a time period associated with the QoS non-fulfillment. In this case, detection of a QoS non-fulfillment comprises detect a QoS non-fulfillment in the downlink if at least one downlink radio link serving the application is indicated as not fulfilling a QoS requirement during a time period defined by the downlink timer; and detect a QoS non-fulfillment in the uplink if at least one uplink radio link serving the application is indicated as not fulfilling a QoS requirement during a time period defined by the uplink timer. The downlink timer and/or the uplink timer may be a timer or time window obtained from the QoS monitoring configuration.

In embodiments where the radio links serving the application are independent radio links configured for packet duplication in the downlink and the uplink, respectively, the detection of a QoS non-fulfillment comprises at least one of detect a QoS non-fulfillment in the downlink if all independent downlink radio links serving the application are indicated as not fulfilling a QoS requirement; and detect a QoS non-fulfillment in the uplink if all independent uplink radio links serving the application are indicated as not fulfilling a QoS requirement. Also in this case the detection of a QoS non-fulfillment may further consider a time period such that detection of a QoS non-fulfillment comprises at least one of detect a QoS non-fulfillment in the downlink if all independent downlink radio links serving the application are indicated as not fulfilling a QoS requirement during a time period defined by the downlink timer; and detect a QoS non-fulfillment in the uplink if all uplink radio links serving the application are indicated as not fulfilling a QoS requirement during a time period defined by the uplink timer.

When the QoS non-fulfillment indication <NUM> provided to the application in step <NUM> has reached the application in the client device <NUM>, the application may perform certain predefined actions in step <NUM>. For example, the application may control the client device <NUM> based on the QoS non-fulfillment indication <NUM>. The application may execute a pre-programmed behaviour which could be one or more precautionary actions. Example of such precautionary actions for V2X could be to decrease the speed of a vehicle, notify a driver to be prepared for increased manual control or to increase the distance between vehicles in case of platooning.

For industrial cases, such as discrete automation, a device may simply halt its current activity. For airborne devices, a drone may hover or return to a predefined location.

In order to inform the application when the QoS is again fulfilled for the radio links serving the application, the client device <NUM> may further monitor for QoS fulfillment. The client device <NUM> may in embodiments monitor for a QoS fulfillment in the one or more radio links based on the QoS monitoring configuration. In such embodiments, the client device <NUM> provides a QoS fulfillment indication <NUM> to the application upon detection of a QoS fulfillment of the one or more QoS requirements. In a similar way as for the detection of QoS non-fulfillment, the detection of QoS fulfillment may be based on at least one downlink and/or uplink radio link serving the application being indicated as fulfilling a QoS requirement, e.g. during a time period defined by the downlink and/or uplink timer. The QoS requirement used to detect QoS fulfillment may be the same or different from the QoS requirement used to detect QoS non-fulfillment.

In other embodiments a timer may be used to restore the QoS status of the radio links serving the application after a QoS non-fulfillment indication. At least one detection method is continuous in nature when configured and QoS non-fulfillment indications are continuously provided to the application when detected. Upon receiving a QoS non-fulfillment indication, the application starts a QoS monitoring timer. The QoS monitoring timer may be configured by the network during the establishment of the PDU session for the application. Every time a new QoS non-fulfillment indication is received, the application will restart the QoS monitoring timer if it is already running. If the QoS monitoring timer expires, the application will assume that the QoS is back to the requested/guaranteed level.

According to the invention the monitoring for QoS non-fulfillment may be activated and configured by the network node <NUM> based on a QoS monitoring activation request <NUM> from the client device <NUM> and/or based on subscription data or QoS flow characteristics. <FIG> shows signaling between the client device <NUM> and the network node <NUM> for activation and configuration of monitoring for QoS non-fulfillment according to such embodiments. In step I in <FIG>, the client device <NUM> transmits a QoS monitoring activation request <NUM> to the network node <NUM>. Step I is an optional step performed in embodiments where the activation is based on an explicit request from the client device <NUM>. The QoS monitoring activation request <NUM> is associated with an application and may request the activation of monitoring for QoS non-fulfillment for a network slice, a PDU session, or a QoS flow. The QoS monitoring activation request <NUM> may be transmitted in any of a REGISTRATION REQUEST message, a PDU SESSION ESTABLISHMENT REQUEST message, and a PDU SESSION MODIFICATION REQUEST message. The QoS monitoring activation request <NUM> may be comprised in an existing or new information element (IE) in any of these messages. For example, the QoS monitoring activation request <NUM> may be comprised in a new IE in the REGISTRATION REQUEST message, and in the 5GSM capability IE in the PDU SESSION ESTABLISHMENT REQUEST message. If the QoS monitoring activation request <NUM> is included in an IE on the top level of these respective messages, QoS monitoring can be requested per network slice with the use of slice service type (SST) and slice differentiator (SD), or requested per PDU Session. If the client device <NUM> wants to enable monitoring for QoS non-fulfillment for a specific QoS flow, then the QoS monitoring activation request <NUM> can be comprised in the QoS flow descriptions IE in the PDU SESSION MODIFICATION REQUEST message. In this way it is possible to differentiate within a PDU session and configure monitoring for QoS non-fulfillment specifically per QoS Flow ID (QFI).

In step II in <FIG>, the network node <NUM> determines whether to activate monitoring for QoS non-fulfillment or not. The determination in step II in <FIG> is based on the QoS monitoring activation request <NUM> associated with the application from the client device <NUM>. Hence, the network node <NUM> in step II in <FIG> determines to activate monitoring for QoS non-fulfillment upon receiving the QoS monitoring activation request <NUM> from the client device <NUM>. The determination in step II in <FIG> may further be based on QoS flow characteristics or subscription data, i.e. without an explicit activation request from the client device <NUM>. Hence, the network node <NUM> may in embodiments determine whether to activate monitoring for QoS non-fulfillment or not without receiving the QoS monitoring activation request <NUM>. When the determination in step II in <FIG> is based on QoS flow characteristics, the 5QI/QFI table may be extended with information indicating whether monitoring for QoS non-fulfillment should be activated for a QFI or not. The monitoring for QoS non-fulfillment information could be added as an attribute or as a note to certain QFls. Hence, the monitoring for QoS non-fulfillment may be implicitly activated based on the QFI of the data traffic for the application. When the determination in step II in <FIG> is based on user subscription data, the monitoring for QoS non-fulfillment activation information could be added as an attribute or as a flag in the subscription data in the unified data management (UDM).

The activation of monitoring for QoS non-fulfillment based on user subscription data enables the monitoring for QoS non-fulfillment to be activated per network slice, PDU session, or QoS flow. When the client device <NUM> requests establishment of a PDU session towards a network slice, the network node <NUM> can check the subscription data with the UDM. If monitoring for QoS non-fulfillment is allowed for the user according to the subscription data, the network node <NUM> can inform the client device <NUM> that monitoring for QoS non-fulfillment can be enabled in the PDU SESSION ESTABLISHMENT ACCEPT message (not shown in <FIG>). During the PDU session establishment procedure, the network node <NUM> can further activate monitoring for QoS non-fulfillment only for those QoS flows for which it is allowed based on subscription data. Whether monitoring for QoS non-fulfillment can be activated or not for each of the QoS flows can then be included in the QoS flow description IE. If the network node <NUM> does not enable monitoring for QoS non-fulfillment for a QoS flow during the PDU SESSION ESTABLISHMENT procedure, the client device <NUM> may request the network node <NUM> to enable it via PDU SESSION MODIFICATION procedure, as previously described.

In step III in <FIG>, the network node <NUM> determines at least one part of a QoS monitoring configuration. The network node <NUM> determines the at least one part of the QoS monitoring configuration based on the QoS monitoring activation request <NUM>. The network node <NUM> determines the QoS monitoring configuration based on the QoS monitoring activation request <NUM> and in dependence on one or more characteristics of QoS flows or IP packet flows associated with the application, wherein the one or more characteristics are at least one of <NUM> QoS identifier, QoS flow identifier, resource type, packet error rate, packet delay budget, survival time and jitter. The network node <NUM> may further considered additional input such as capabilities of the client device <NUM> and capability and capacity of the network access node serving the client device <NUM>. The QoS monitoring configuration may indicate at least one of: a QoS monitoring rule, information of downlink radio links serving the application, a downlink timer associated with the downlink radio links, information of uplink radio links serving the application, an uplink timer associated with the uplink radio links, and a QoS threshold value.

When the network node <NUM> has determined the QoS monitoring configuration <NUM>, the network node <NUM> transmits the QoS monitoring configuration <NUM> to the client device <NUM> in step IV in <FIG>. In the embodiment shown in <FIG>, the client device <NUM> receives the QoS monitoring configuration <NUM> from the network node <NUM> in response to transmission of the QoS monitoring activation request <NUM> to the network node <NUM>. Based on the received QoS monitoring configuration <NUM>, the client device <NUM> monitors for a QoS non-fulfillment in one or more radio links serving the application in step V in <FIG>. As previously described, the client device <NUM> may further derive at least one part of the QoS monitoring configuration based on a predefined rule. The monitoring in step V in <FIG> may be performed according to the method <NUM> described above.

According to embodiments of the invention the client device <NUM> provides a report <NUM> to the network node <NUM>, where the report <NUM> indicates information about the QoS non-fulfillment, as shown in step VI in <FIG>. The network node <NUM> can in this case be the corresponding application in the data network, a node in the core network, or a network access node. The client device <NUM> may provide the report <NUM> to the network node <NUM> in a SOAP report or in an application layer report. When the SOAP report is used, the report information can be conveyed as a new control PDU or new header information piggybacked with a data PDU. The application in the client device <NUM> may control the providing of the application layer report to the network node <NUM>. The application may use all potential available wireless links for transmission of the report <NUM>, to increase reliability. Furthermore, non-access stratum (NAS) can be used to provide the report <NUM>. In this case, the report <NUM> may be transmitted using e.g. a new signalling message over a N1 interface or a NAS control message over a non-3GPP link.

In embodiments, the network node <NUM> may be a network node <NUM> and a network access node <NUM> and the functions of the network node <NUM> may be split between the network node <NUM> and the network access node <NUM>. <FIG> shows signaling between the client device <NUM>, the network node <NUM>, and the network access node <NUM> for activation and configuration of monitoring for QoS non-fulfillment according to such embodiments. In the embodiment shown in <FIG>, the determination whether to activate monitoring for QoS non-fulfillment is performed in the network node <NUM> in step I, e.g. by a session management function (SMF) in the network node <NUM>. As previously described, the determination may be based on the QoS monitoring activation request <NUM> from the client device <NUM> and/or based on subscription data or QoS flow characteristics. If the network node <NUM> determines to activate monitoring for QoS non-fulfillment, the network node <NUM> provides a QoS monitoring activation request <NUM>' to the network access node <NUM>, as shown in step II in <FIG>. For example, configuration for activation of monitoring for QoS non-fulfillment may be added to the signalling between the network node <NUM> and the network access node <NUM>, such that e.g. the access management function (AMF) in the network node <NUM> can request setup of monitoring for QoS non-fulfillment from the network access node <NUM>, either for a PDU session or for specific QFI within a PDU Session.

Based on the QoS monitoring activation request <NUM>', the network access node <NUM> determines at least a part of the QoS monitoring configuration <NUM> in step III in <FIG>. For example, based on the characteristics of the QoS flow where monitoring for QoS non-fulfillment have been requested the network access node <NUM> will derive the specific settings of parameters for the different detection mechanism to be used in the client device <NUM>. The network access node <NUM> further transmits the determined QoS monitoring configuration <NUM> to the client device <NUM>, as shown in step IV in <FIG>. The QoS monitoring configuration <NUM> may e.g. be comprised in a RRC configuration message. In this case, the RRC configuration messages for the Uu interface is extended with parameters for monitoring for QoS non-fulfillment.

In step V in <FIG>, the client device <NUM> monitors for a QoS non-fulfillment in one or more radio links serving the application based on the received QoS monitoring configuration <NUM> and/or the QoS monitoring configuration derived based on the predefined rule.

According to embodiments the client device <NUM> obtains the QoS monitoring configuration in a first layer, monitors for a QoS non-fulfillment in the one or more radio links in a third layer and provides QoS indications from the third layer to a second layer. In such embodiments, the client device <NUM> detects a QoS non-fulfillment of the one or more QoS requirements in the second layer based on QoS indications provided by the third layer. The first layer may be radio resource control (RRC) or non access stratum (NAS), the second layer may be packet data convergence protocol (PDCP) or medium access control (MAC), and the third layer may be medium access control (MAC) or physical layer (PHY).

<FIG> shows configuration of monitoring for QoS non-fulfillment in the client device <NUM> according to an embodiment of the invention. In <FIG>, the RRC layer obtains the QoS monitoring configuration <NUM> e.g. from the network node <NUM> and configures the lower layers to monitor and detect QoS non-fulfillment. The RRC layer may obtain the QoS monitoring configuration <NUM> in response to an QoS monitoring activation request <NUM> originating from the application in the client device <NUM> and transmitted to the network node <NUM> via the NAS layer. In the embodiment shown in <FIG>, it is assumed that detection of QoS non-fulfillment should be performed in the PDCP layer and monitoring for QoS non-fulfillment should be performed in both the MAC layer and the PHY layer. Thus, the RRC layer provides QoS monitoring configuration 504a to configure the PDCP layer to perform detection of QoS non-fulfillment. The RRC layer further provides QoS monitoring configurations 504b, 504c to the MAC layer and the PHY layer, respectively, to configure the MAC layer and the PHY layer to perform monitoring for QoS non-fulfillment.

<FIG> shows indication of QoS non-fulfillment in the client device <NUM> according to embodiments of the invention. In the embodiment shown in <FIG>, monitoring for QoS non-fulfillment is performed both in the PHY layer and the MAC layer. Furthermore, detection of QoS non-fulfillment is performed in the PDCP layer. Thus, the client device <NUM> monitors for a QoS non-fulfillment in the PHY layer and the MAC layer and provide QoS indications <NUM> from the PHY layer and the MAC layer to the PDCP layer. As shown in <FIG>, the QoS indications <NUM> are passed via one or more higher layer to the PDCP layer. A QoS non-fulfillment of the one or more QoS requirements in the PDCP layer is detected based on the QoS indications <NUM> provided by the PHY layer and/or MAC layer and a QoS non-fulfillment indication <NUM> is generated. The QoS non-fulfillment indication <NUM> is provided by the PDCP layer to the application via one or more higher layers.

According to embodiments of the invention the client device <NUM> provides the QoS non-fulfillment indication to the application via at least one of service data adaptation protocol (SOAP) layer, a radio link control (RLC) layer, and an intermediate layer, wherein the intermediate layer is arranged above the SOAP layer but below the application layer. In embodiments where the client device <NUM> provides the QoS non-fulfillment indication to the application via the SOAP layer, the client device <NUM> may perform reverse access stratum mapping in the SOAP layer so as to identify one or more QoS flows associated with the application upon detection of non-fulfillment of the one or more QoS requirements. The reverse access stratum mapping in the SOAP layer is hence triggered by the detection of a non-fulfillment of the one or more QoS requirements and is performed to map each affected radio link to a QoS flow. For example, the SOAP layer gets an indication from the PDCP layer indicating which data radio bearers (DRBs) are impacted by the non-fulfillment of the one or more QoS requirements. Access stratum mapping is the mapping received from the radio access network to map the QoS flows to DRBs in the uplink. Hence, the SOAP layer may apply reverse access stratum mapping to, from the DRBs, identify which QoS flows are impacted by the non-fulfillment of the one or more QoS requirements. The SOAP layer may then indicate the identified QoS flows to the intermediate layer, where the intermediate layer is one or more layers between SOAP and the application.

In embodiments where the client device <NUM> provides the QoS non-fulfillment indication to the application via the intermediate layer, the client device <NUM> may apply a packet filter in reverse in the intermediate layer so as to identify the application upon detection of non-fulfillment of the one or more QoS requirements. The application of the packet filter in reverse in the intermediate layer is hence triggered by the detection of a non-fulfillment of the one or more QoS requirements and is applied to identify the application from one or more QoS flows impacted by the non-fulfillment of the one or more QoS requirements. For example, the intermediate layer may receive an indication from the SOAP layer, as described above, which identifies QoS flows impacted by the non-fulfillment of the one or more QoS requirements. The reverse action can be understood to mean that the intermediate layer goes through the QoS rules and find the QoS rule applicable to the impacted QoS flows, extracts the relevant packet filter information, e.g. source port, source address etc., and send this information to higher layers, e.g. the IP stack in the application.

In embodiments where dual connectivity and/or carrier aggregation is used, with or without packet duplication, the invention provides different ways of filtering the QoS indications from the third layer in the second layer. The radio bearer configuration from the network shall include for each logical channel, for which monitoring for QoS non-fulfillment is configured, the number of independent radio links and a timer. The independent radio links may further be specific for downlink and uplink. Further details related to different detection and filtering embodiments will now be described with reference to <FIG>.

<FIG> shows an embodiment where detection of QoS non-fulfillment for uplink radio links is performed in the PDCP layer based on filtering of QoS indications <NUM> from the MAC layer. In <FIG>, two independent radio links are available for uplink transmission and are monitored for QoS non-fulfillment in the MAC layer. The two independent radio links are associated with a first RLC entity RLC <NUM> and a second RLC entity RLC2, respectively, in the RLC layer. Filtering of the QoS indications <NUM> from the MAC layer, via the RLC layer, is performed in the PDCP layer based on a counter per PDCP packet and an uplink timer Tup. The uplink timer Tup is started when a packet is received in the PDCP layer from higher layers and passed to the MAC layer, via the RLC layer. In the embodiment shown in <FIG>, a packet is received and the uplink timer Tup is hence started at time instance t1. For each QoS indication <NUM> received from the MAC layer in the PDCP layer the counter is incremented. If a predefined number of QoS indications for the packet are received within the uplink timer Tup, the PDCP layer detects a QoS non-fulfillment and provides a QoS non-fulfillment indication <NUM> to the application. The predefined number of QoS indications may e.g. be larger than or equal to the number of independent radio links. If the predefined number of QoS indications are not received within the uplink timer Tup, any received QoS indication <NUM> is discarded. In the embodiment shown in <FIG>, it is assumed that the predefined number of QoS indications is set to two. In <FIG>, two QoS indications <NUM> are received before the uplink timer Tup expires, one from each independent radio link, therefore a QoS non-fulfillment indication <NUM> is triggered. In <FIG>, the QoS indication <NUM> is provided to the application via the SOAP layer.

<FIG> shows an embodiment where detection of QoS non-fulfillment for downlink radio links is performed in the MAC layer based on filtering of QoS indications <NUM> from the PHY layer. In <FIG>, two independent radio links, i.e. two separate component carriers (CCs), CC1, CC2 are available for downlink transmission and are monitored for QoS non-fulfillment in the PHY layer. The two independent radio links CC1, CC2 are connected to one QoS flow in higher layers. In a similar way as for the uplink detection described with reference to <FIG>, the QoS indications <NUM> are filtered based on a counter and a timer. Hence, filtering of the QoS indications <NUM> from the PHY layer is performed in the MAC layer based on a counter per QoS indication and a downlink timer Tdown. The downlink timer Tdown is started upon reception of a QoS indication <NUM>, which in <FIG> is at time instance t1. If QoS indications <NUM> are not received from all independent radio links during the downlink timer Tdown any received QoS indication <NUM> is discarded. In <FIG>, a QoS indication <NUM> is received from the second component carrier CC2 before the downlink timer Tdown expires, therefore a QoS non-fulfillment indication <NUM> is triggered. In <FIG>, the QoS indication <NUM> is provided to the application via the RLC layer and the PDCP layer. Note that when carrier aggregation is configured the network node <NUM> may in embodiments configure monitoring for QoS non-fulfillment for only one of the carriers.

The client device <NUM> herein, may be denoted as a user device, a User Equipment (UE), a mobile station, an internet of things (IoT) device, a sensor device, a wireless terminal and/or a mobile terminal, is enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The UEs may further be referred to as mobile telephones, cellular telephones, computer tablets or laptops with wireless capability. The UEs in this context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another receiver or a server. The UE can be a Station (STA), which is any device that contains an IEEE <NUM>-conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The UE may also be configured for communication in 3GPP related LTE and LTE-Advanced, in WiMAX and its evolution, and in fifth generation wireless technologies, such as New Radio.

The network node <NUM> may comprise as least one of a session management function (SMF), an access and mobility management function (AMF), a policy control function (PCF), a unified data management (UDM), or a user plane function (UPF).

The network access node <NUM> may be denoted as a radio network access node, an access network access node, an access point, or a base station, e.g. a Radio Base Station (RBS), which in some networks may be referred to as transmitter, "gNB", "gNodeB", "eNB", "eNodeB", "NodeB" or "B node", depending on the technology and terminology used. The radio network access nodes may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. The radio network access node can be a Station (STA), which is any device that contains an IEEE <NUM>-conformant Media Access Control (MAC) and Physical Layer (PHY) interface to the Wireless Medium (WM). The radio network access node may also be a base station corresponding to the fifth generation (<NUM>) wireless systems.

Moreover, it is realized by the skilled person that embodiments of the client device <NUM> and the network node <NUM> comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, MSDs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Claim 1:
A client device (<NUM>) for a wireless communication system (<NUM>), the client device (<NUM>) being configured to:
• transmit a Quality-of-Service, QoS, monitoring activation request (<NUM>) to a network node (<NUM>);
• obtain a QoS monitoring configuration associated with an application of the client device (<NUM>), wherein the obtaining the QoS monitoring configuration comprises:
∘ receiving the QoS monitoring configuration associated with the application of the client device (<NUM>) from the network node (<NUM>) in response to the transmission of the QoS monitoring activation request (<NUM>) to the network node (<NUM>);
• monitor for a QoS non-fulfillment in one or more radio links serving the application based on the received QoS monitoring configuration; and
• provide a QoS non-fulfillment indication (<NUM>) to the application upon detection of a QoS non-fulfillment of one or more QoS requirements obtained from the QoS monitoring configuration.