Patent Description:
Some example embodiments may generally relate to mobile or wireless telecommunication systems, such as <NUM>rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), <NUM>th generation (<NUM>) radio access technology (RAT), new radio (NR) access technology, <NUM>th generation (<NUM>), and/or other communications systems. For example, certain example embodiments may relate to systems and/or methods for using quality of service to control multicast reception of user equipment.

Examples of mobile or wireless telecommunication systems may include radio frequency (RF) <NUM> RAT, the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), LTE Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), LTE-A Pro, NR access technology, and/or MulteFire Alliance. <NUM> wireless systems refer to the next generation (NG) of radio systems and network architecture. A <NUM> system is typically built on a <NUM> NR, but a <NUM> (or NG) network may also be built on E-UTRA radio. It is expected that NR can support service categories such as enhanced mobile broadband (eMBB), ultra-reliable low-latency-communication (URLLC), and massive machine-type communication (mMTC). NR is expected to deliver extreme broadband, ultra-robust, low-latency connectivity, and massive networking to support the Internet of Things (IoT). The next generation radio access network (NG-RAN) represents the radio access network (RAN) for <NUM>, which may provide radio access for NR, LTE, and LTE-A. It is noted that the nodes in <NUM> providing radio access functionality to a user equipment (e.g., similar to the Node B in UTRAN or the Evolved Node B (eNB) in LTE) may be referred to as next-generation Node B (gNB) when built on NR radio, and may be referred to as next-generation eNB (NG-eNB) when built on E-UTRA radio. Publication <CIT>describes method performed by a network node in a telecommunication network providing a multicast transmission to a group of devices residing in a cell of the telecommunication network. Publication <CIT>relates to methods and systems for RRC state maintenance for receiving multicast and broadcast services. Publication <CIT> describes a communication control method implemented by user equipment in a mobile communication system providing a multicast/broadcast service (MBS).

The invention is defined in the appended apparatus claims <NUM> and <NUM>, and corresponding method claims <NUM> and <NUM>. Specific embodiments are defined in the dependent claims.

For a proper understanding of example embodiments, reference should be made to the accompanying drawings, wherein:.

It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for using QoS to control multicast reception of UE is not intended to limit the scope of certain example embodiments, but is instead representative of selected example embodiments.

In 3GPP Release (Rel)-<NUM>, NR MBS may be allowed for UE to only receive multicast while in RRC_CONNECTED state. Point-to-multipoint (PTM) transmissions may efficiently provision MBS services to multiple users by using the same radio framework as unicast transmissions. 3GPP Rel-<NUM> enabled reception of a multicast service by the UEs only in RRC_CONNECTED state, which may improve reliability of data reception via hybrid automatic repeat request (HARQ) retransmissions and dynamic modulation and coding scheme (MCS) selection, even for PTM operations.

3GPP Rel-<NUM> identified and evaluated further enhancements to the 5GS architecture to provide MBS. In particular, reception of multicast services by the UE may be enabled in an RRC_INACTIVE state for scalability and power saving purposes. When a UE is in an RRC_INACTIVE state, it may apply the configuration of the multicast service in the cell to start/continue receiving a multicast service that the UE has joined.

One option is to provide the configuration using a method similar to the 3GPP Rel-<NUM> broadcast (i.e., cell broadcasts system information block (SIB)/multicast control channel (MCCH) periodically, enabling RRC_INACTIVE UEs to receive the configuration and related updates). Alternatively, the UE may receive the configuration of multicast reception for all cells in the RAN notification area (RNA) while transitioning to an RRC_INACTIVE state. SIB/MCCH may then provide further information in the cells on the current state of multicast services. In addition, it may be possible that the UE receives some of the configuration via dedicated signaling, while some other portion may be signaled via SIB/MCCH (i.e., mixed mode of configuration). In addition, UEs in RRC_CONNECTED and RRC_INACTIVE states may simultaneously receive the same multicast data (e.g., physical downlink shared channel (PDSCH)) and physical downlink control channel (PDCCH) that schedules the data.

Small data transmission (SDT) relates to allowing the UE to receive and transmit data while in an RRC_INACTIVE state (i.e., without transitioning to RRC_CONNECTED state). SDT may be enabled on a radio bearer basis and may be initiated by the UE based only on configured thresholds (e.g., if less than a configured amount of uplink (UL) data awaits transmission across all radio bearers for which SDT is enabled, or the downlink (DL) reference signal received power (RSRP) is above a configured threshold, such as shown in the flowchart of <FIG> of an SDT configuration).

SDT procedures may be initiated with either a transmission over RACH (e.g., configured via system information) or over Type <NUM> configured grant (CG) resources (e.g., configured via dedicated signaling in RRCRelease).

<FIG> depicts an example of a <NUM>-step RACH-based SDT, wherein the selection of a physical random access channel (PRACH) preamble dedicated for SDT and/or selection of SDT-specific RACH occasion may indicate a need for an SDT transmission to the network. Although SDT-specific RACH resources (e.g., RACH occasion (RO) + preamble combination) may be assumed, use of common RACH resources may not be precluded if possible via implementation (e.g., not supported by explicit mechanism). MSG3/MSGA size may be such that the UE may multiplex the UL data in the medium access control (MAC) protocol data unit (PDU) with the radio resource control (RRC) resume request message to provide necessary control information.

3GPP groups have agreed that HARQ feedback and point-to-point (PTP) retransmissions are not supported for multicast reception in RRC_INACTIVE state. Due to a lack of feedback UL communication in RRC_INACTIVE state (e.g., no UL communication while the UE is in RRC_INACTIVE to send UL HARQ feedback), the network may be unable to monitor, and thus improve MBS service delivery for UEs in RRC_INACTIVE state, unlike UEs in RRC_CONNECTED state. Thus, if there are UEs receiving the same service in RRC_INACTIVE and RRC_CONNECTED states, the gNB may only perform link adaptation based on the feedback of the UEs in RRC_CONNECTED. If there are only UEs in RRC_INACTIVE state, the network may not perform link adaptation for that multicast service.

As a result, MBS reception quality of certain UEs that are in RRC_INACTIVE state may be significantly below the QoS level for the multicast session required as per received QoS flows/QoS parameters. If the gNB decides to keep a portion of the total MBS UEs in RRC_CONNECTED state, and send another portion of UEs in RRC_INACTIVE state (e.g., due to congestion). Reliability of UEs in RRC_INACTIVE may be improved via network implementation (e.g., repetition); however, this may conflict with the purpose of MBS (i.e., resource optimization).

In order to manage the QoS of the UE in RRC_INACTIVE state, some proposals suggest to configure the UE via dedicated signaling with a QoS threshold for the RRC_INACTIVE UEs, and whenever the UE experiences a QoS less than the defined threshold value, the UE may return to an RRC_CONNECTED state. However, in high-congestion scenarios, it may be difficult for the gNB to accommodate all the RRC_INACTIVE UEs into RRC_CONNECTED states at the same time when several UEs attempt to reconnect. It is noted that enabling RRC_INACTIVE multicast reception can target scalability, with many UEs receiving the same multicast service. In addition, RACH congestion may occur in some situations. However, the gNB currently cannot dynamically control such behavior of the UE.

In light of the discussion above, there are several disadvantages with current techniques. For example, there may be a lack of dynamic network control, where UEs may resume to RRC_CONNECTED, while the network remains congested. RRC_INACTIVE reception provides scalability, and therefore, many UEs may be in the same cell receiving multicast in RRC_INACTIVE state. Furthermore, there may be inefficiency with power consumption and resource utilization due to the UE continuously trying to return to an RRC_CONNECTED state, although the network would reject a connection from the UE.

An example technique is depicted in <FIG>. The UE may send a measurement report to the gNB only in an RRC_CONNECTED state. For example, the UE may be configured such that if the UE experiences a measured QoS below a predefined threshold level, the UE may transition to RRC_CONNECTED state using RRCResumeRequest procedure. The UE may autonomously decide when to switch to RRC_CONNECTED state, without control by the gNB. In addition, each UE experiencing degraded service/QoS may return to RRC_CONNECTED to notify the gNB. The RRC_INACTIVE UE may be configured with a single QoS threshold, and whenever the QoS of an RRC_INACTIVE UE falls below the threshold level, the UE automatically and autonomously transitions to RRC_CONNECTED state and notifies the gNB.

Certain example embodiments described herein may have various benefits and/or advantages to overcome the disadvantages described above. For example, certain example embodiments may provide the gNB with more dynamically controllable QoS thresholds, particularly controlled based on congestion and/or scalability conditions. This may maximize the QoS experienced by UEs when receiving MBS sessions in RRC_INACTIVE at any point in time, and ensuring that scalability requirements are met at any point in time, while considering scalability requirements in light of QoS requirements. In addition, this may enable UEs receiving MBS in RRC_INACTIVE state to improve their QoS by sending feedback to the network. Thus, certain example embodiments discussed below are directed to improvements in computer-related technology.

Certain example embodiments described herein relate to techniques to control QoS that can support i) the gNB to dynamically control the RRC_INACTIVE UEs in the cell more efficiently, and ii) improve synchronization between RRC_INACTIVE UEs and the gNB during degraded QoS. This may accomplished by an RRC_INACTIVE UE i) measuring and monitoring the quality of the MBS data reception, and ii) notifying the gNB when QoS degrades below a threshold level. The network may then determine to transition the UE to RRC_CONNECTED for an improved MBS reception (e.g., via PTP + PTM). Some example embodiments may incorporate the use of multicast channel (MCH) block error rate (BLER) monitoring, service data adaption protocol (SDAP), layer <NUM> (L1)/layer <NUM> (L3) measurements, and quality of experience (QoE) measurement collection methods. Some example embodiments may improve synchronization between RRC_INACTIVE UEs and the gNB during degraded QoS; specifically, when the UE measures and monitors the reception quality, observes that there is degradation in the QoS, and indicates the degradation to the gNB.

In various example embodiments, a NE may transmit more than one QoS threshold configuration, each comprising at least one QoS threshold, wherein each of the QOS threshold configurations are associated with a QoS threshold configuration identifier.

In certain example embodiments, a NE may select a first QoS threshold configuration from among more than one QoS threshold configuration, and transmit, to a UE, the QoS threshold configuration identifier associated with the first QoS threshold configuration via broadcast SIB or MCCH.

In some example embodiments, the transmitting may include transmitting at least one of the QoS thresholds.

In various example embodiments, each QoS threshold configuration may include at least one QoS parameters set, and each QoS parameters set may include more than one QoS parameter.

In certain example embodiments, the NE may select a time window where at least one of the QoS threshold configurations is applicable, and transmit the selected time window to the UE.

In some example embodiments, the NE may set a priority value for each of the QoS threshold configuration identifiers, select a QoS threshold configuration identifier, and transmit the priority value corresponding with the selected QoS threshold configuration identifier via SIB or MCCH.

In various example embodiments, the NE may transmit, to the user equipment, a priority value associated with each quality of service threshold configuration identifier, and broadcast, to the user equipment, a priority threshold.

In some example embodiments, the NE may receive, from the UE, a QoS degradation status using uplink SDT.

In certain example embodiments, a UE may receive, from a network entity, more than one QoS threshold configuration each comprising at least one QOS threshold, wherein each of the QoS threshold configurations are associated with a QoS threshold configuration identifier; receive, from the network entity, one of the QoS threshold configuration identifiers; measure a QoS for each of the QoS thresholds of the QoS threshold configuration associated with the received QoS threshold configuration identifier; and determine a RRC state based upon a comparison of the measured QoS being above or below a respective QoS threshold of each of the QoS thresholds of the QoS threshold configuration associated with the received QoS threshold configuration identifier.

In some example embodiments, each QoS threshold configuration may include at least one QoS parameters set, and each QoS parameters set may include more than one QoS parameter.

In various example embodiments, the UE may determine that the measured QoS is above the QoS threshold level for at least one of the QoS thresholds in the identified QoS threshold configuration; and remain in a RRC inactive state.

In certain example embodiments, the UE may determine that at least one of the measured QoSs are below the QoS threshold level of the QoS thresholds in the identified QoS threshold configuration, and send a request to transition to a RRC connected state.

In some example embodiments, the UE may determine that the measured QoS is below the QoS threshold level for at least one of the QoS thresholds in the identified QoS threshold configuration, and remain in a RRC inactive state.

In various example embodiments, the UE may determine that at least one of the measured QoSs is above the QoS threshold level of the QoS thresholds in the identified QoS threshold configuration, and send a request to transition to a RRC connected state.

In certain example embodiments, the UE may determine that the measured QoS equals the QoS threshold level for at least one of the QoS thresholds comprised in the identified QoS threshold configuration, and send a request to transition to a RRC connected state.

In some example embodiments, the UE may determine that the measured QoS equals the QoS threshold level for at least one of the QoS thresholds comprised in the identified QoS threshold configuration, and remain in a RRC inactive state.

In various example embodiments, the QoS threshold configuration identifier may be received via broadcast SIB or MCCH.

In certain example embodiments, the UE may receive, from a network entity, a time window associated with the at least one of the QoS threshold configurations; determine if current time matches the received time window; and determine whether to measure when the current time matches the received time window.

In some example embodiments, the UE may receive, from the network entity, a priority value corresponding with a selected QoS threshold configuration identifier via SIB or MCCH, and determine whether to measure a QoS associated with a corresponding QoS threshold configuration when the priority threshold received for the QoS threshold configuration is above the received priority value.

In various example embodiments, the UE receive, from the network entity, a priority value associated with each QoS threshold configuration identifier, and receive, from the network entity, a priority threshold via broadcast.

In certain example embodiments, the priority value may be received over a broadcast channel.

In some example embodiments, the UE may transmit, to the network entity, a QoS degradation status using an uplink SDT procedure.

In various example embodiments, the UE may receive, from the network entity, a priority value associated with each QoS threshold configuration identifier, receive, from the network entity, a priority threshold via broadcast, and apply the QoS threshold configuration associated with the priority value that is above the priority threshold.

<FIG> illustrates an example of a signaling diagram for defining one or multiple MBS sessions, and multiple threshold levels, for a QoS parameter and applicable time windows. NE <NUM> and UE <NUM> may be similar to NE <NUM> and UE <NUM>, as illustrated in <FIG>, according to certain example embodiments.

In general, one QoS threshold level may be defined for RRC_INACTIVE UEs, such as UE <NUM>. Thus, whenever UE <NUM> experiences QoS less than a threshold level, UE <NUM> may switch to RRC_CONNECTED state. Multiple QoS threshold values are defined/configured by NE <NUM> for UEs receiving in RRC_INACTIVE state.

At <NUM>, NE <NUM> may configure UE <NUM> with multiple levels of QoS thresholds (i.e., ID<NUM>, ID<NUM>, ID<NUM>,. ), for example, Th_high (represented by ID<NUM>) and Th_low (represented by ID<NUM>), where Th_high > Th_low. The QoS thresholds may also set different parameters; for example, Th_high may contain delay and average throughput conditions. At <NUM>, UE <NUM> may enter, or already be in, an RRC INACTIVE state.

At <NUM>, NE <NUM> may determine that a high level of network congestion is occurring, and decide to use one of the QoS thresholds (e.g., Th_low, ID<NUM>), and allow a limited number of UEs that are experiencing severe QoS degradation to switch to RRC_CONNECTED state. At <NUM>, based upon network conditions (e.g., load, congestion), NE <NUM> may broadcast to all UEs, including UE <NUM>, to use at least one of the threshold values from <NUM> by broadcasting the ID of the corresponding threshold (i.e., not broadcasting the threshold itself). For example, if NE <NUM> is experiencing high congestion, NE <NUM> may notify via broadcast (e.g., SIB/MCCH) the RRC_INACTIVE UEs to use Th_low by broadcasting the ID associated with Th_low, such that only a few of the RRC_INACTIVE UEs that are experiencing severe QoS degradation conditions may enable switching to RRC_CONNECTED state.

In certain example embodiments, NE <NUM> may directly broadcast over MCCH "threshold levels" that UEs (e.g., UE <NUM>) receiving the MBS session in RRC_INACTIVE state should follow, rather than broadcasting the threshold via dedicated signaling. This may occur since UE <NUM> constantly monitors the threshold levels over MCCH to determine whether they have been fulfilled.

In some example embodiments, NE <NUM> may configure the UEs (e.g., UE <NUM>) with one or more threshold values on a per cell basis and/or configure each threshold value for one or multiple MBS sessions. If configured for multiple MBS sessions, the threshold level may be applied based upon a priority threshold of the MBS session (i.e., apply the threshold parameter only for MBS sessions of priority higher than <NUM>).

In various example embodiments, NE <NUM> may broadcast a congestion indicator, such that when the congestion indicator is set to "TRUE," all UEs which have been configured with threshold levels apply them, as described above. However, when the congestion indicator is set to 'FALSE,' or not broadcasted, the threshold level parameters may not be used by UE <NUM>.

At <NUM>, UE <NUM> may set ID<NUM> as the QoS threshold level. At <NUM>, UE <NUM> may measure that QoS is less than ID<NUM> but more than ID<NUM>. As a result, UE <NUM> may remain in RRC_INACTIVE state. At <NUM>, UE <NUM> may measure QoS again, and determine that QoS is less than ID<NUM>. At <NUM>, UE <NUM> may transmit to NE <NUM> an RRCResumeRequest.

At <NUM>, NE <NUM> may determine that network congestion occurring has fallen below a certain lower level, and decide to use a less-stringent QoS thresholds (e.g., Th_high, ID<NUM>). At <NUM>, based upon network conditions (e.g., load, congestion), NE <NUM> may broadcast to all UEs, including UE <NUM>, to use the less-stringent threshold value by broadcasting the ID of the threshold. This may enable more UEs to resume RRC_CONNECTED state.

At <NUM>, UE <NUM> may set ID<NUM> as the QoS threshold level. At <NUM>, UE <NUM> may measure that QoS is less than ID<NUM>. At <NUM>, UE <NUM> may transmit to NE <NUM> an RRCResumeRequest.

<FIG> illustrates an example of a signaling diagram for defining one or multiple MBS sessions, and multiple threshold levels, for a QoS parameter and applicable time windows. NE <NUM> and UE <NUM> may be similar to NE <NUM> and UE <NUM>, as illustrated in <FIG>, according to certain example embodiments. Multiple QoS threshold values are defined/configured by NE <NUM> for UEs receiving in RRC_INACTIVE state. Based on the time period, UE <NUM> may apply the appropriate threshold values; thus, there is no need for NE <NUM> to broadcast new thresholds each time there is a change in congestion levels. <FIG> is a variation of the embodiments described in <FIG>, wherein multiple levels of QoS thresholds and time windows may be defined.

At <NUM>, NE <NUM> may configure UE <NUM> with multiple levels of QoS thresholds for different time windows (e.g., ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>; ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>). At <NUM>, UE <NUM> may transition to, or already be in, an RRC_INACTIVE state.

In various example embodiments, NE <NUM> may predict different congestion levels (e.g., high: radio congestion level is above <NUM>%; moderate: radio congestion level is <NUM>-<NUM>%; low: radio congestion level is below <NUM>%) at different peak hours (e.g., T<NUM>, T<NUM>, T<NUM>,. Based on internal algorithms, NE <NUM> may be configured to predict different congestion levels at different time periods, and accordingly, derive the optimized QoS threshold levels, which is configured at UE <NUM>. The predictions may be derived statistically and/or obtained from a self-organizing network (SON)/automation/AI/ML network functions/modules that are available (e.g., network data analytics function (NWDAF)). Similarly, NE <NUM> may derive non-peak hours and/or optimized threshold levels application within various time windows. By configuring UE <NUM> with these values, NE <NUM> does not need to broadcast new thresholds during peak/non-peak hours, and UE <NUM> may apply the configured thresholds during the time window.

An example of peak hours could include thresholds such as Tph (high peak hour threshold) = T<NUM> (9AM) - T<NUM> (10AM), T<NUM> (6PM) - T<NUM> (8PM); Tpm (moderate peak hour threshold) = T<NUM> (8PM) - T<NUM> (9PM), T<NUM> (8PM) - T<NUM> (9PM); and Tpl (low peak hour threshold) = T<NUM> (9PM) - T<NUM> (10PM).

Similarly, an example of non-peak hours could include thresholds such as Tnph (high non-peak hour threshold) = T<NUM> (12AM) - T<NUM> (8AM), T<NUM> (10AM) - T<NUM> (6PM); and Tnpl (low non-peak hour threshold) = T<NUM>(10PM) - T<NUM>(12AM).

At <NUM>, UE <NUM> may set ID<NUM> as a QoS threshold level with a specified time window.

At <NUM>, when the time is between T<NUM>-T<NUM>, UE <NUM> may monitor that QoS is more than ID<NUM>. Thus, UE <NUM> may remain in RRC_INACTIVE state.

At <NUM>, UE <NUM> may determine that QoS has fallen below ID<NUM>.

At <NUM>, UE <NUM> may transmit to NE <NUM> an RRCResumeRequest.

At <NUM>, UE <NUM> may set ID<NUM> (e.g., threshold level <NUM> in time T<NUM> - T<NUM>) as the QoS threshold level.

<FIG> illustrates an example of a signaling diagram for defining one or multiple MBS sessions, and optionally one or more conditional QoS parameter sets, and applicable time windows. NE <NUM> and UE <NUM> may be similar to NE <NUM> and UE <NUM>, as illustrated in <FIG>, according to certain example embodiments. <FIG> is a variation of the embodiments described in <FIG> and <FIG>.

At <NUM>, NE <NUM> may configure UE <NUM> with one or more conditional QoS parameter sets, wherein each QoS parameter set may be associated with an ID (e.g., parameter set <NUM> with ID<NUM> should be used at time window T<NUM> (if applied); parameter set <NUM> with ID<NUM> should be used at time window T<NUM>). Each conditional QoS parameter set may include a set of QoS parameters, such that if any QoS parameter is not fulfilled, UE <NUM> may reconnect, as described in <FIG> or <FIG>, and/or send an indication over SDT using the techniques described in <FIG> (discussed below). In some other embodiments, UE <NUM> may reconnect, as described in <FIG> or <FIG>, and/or send an indication over SDT using the techniques described in <FIG> (discussed below) only when all the QoS parameters within the QoS parameter set are not fulfilled. At <NUM>, UE <NUM> may transition to, or already be in, an RRC_INACTIVE state, and be receiving MBS data.

At <NUM>, NE <NUM> may broadcast over SIB/MCCH which conditional parameter set IDs UE <NUM> should apply in a given cell at a given point in time. If NE <NUM> uses a dedicated configuration for RRC_INACTIVE UEs, it may configure ID<NUM> with the selected time window (if applicable) in UE <NUM> when UE <NUM> was in RRC_CONNECTED state.

At <NUM>, UE <NUM> may measure the parameters in ID<NUM> and/or ID<NUM>, and check whether all parameter conditions are met. For example, RRC_INACTIVE UE <NUM> may constantly monitor the conditional QoS parameters sets according to the ID broadcast over MCCH, and possibly the current time to check whether all parameters are fulfilled.

At <NUM>, if UE <NUM> determines that ID<NUM> and/or ID<NUM> parameter conditions are satisfied, UE <NUM> may remain in RRC_INACTIVE state. If all the parameter conditions are fulfilled, UE <NUM> may continue to receive the MBS data in RRC_INACTIVE state. Alternatively, if at <NUM>, UE <NUM> determines that ID<NUM> and/or ID<NUM> parameter conditions are not satisfied, at <NUM>, UE <NUM> may transmit to NE <NUM> an RRCResumeRequest, or use SDT to notify NE <NUM> of the QoS level/value. If any of QoS conditions are not fulfilled, UE <NUM> may reconnect as in <FIG> or <FIG>, and/or send an indication over SDT using techniques described in <FIG>.

In certain example embodiments, NE <NUM> may directly broadcast over MCCH conditional QoS parameter sets which UE <NUM> (receiving the MBS session in RRC_INACTIVE state, from <NUM>) should follow. These conditional QoS parameters sets may include a set of QoS parameters, such that if any of them are not fulfilled, UE <NUM> may reconnect as described in <FIG>, and/or send an indication over SDT the techniques described in <FIG>. UE <NUM> may constantly monitor the conditional QoS parameters sets broadcast over MCCH to check whether all parameters are fulfilled.

In various example embodiments, NE <NUM> may associate a time window with any of the conditional QoS parameter sets. For example, at a given point in time, UE <NUM> may only consider the conditional QoS parameters sets if the current time falls within the time window. The time window may either be configured in the UE, together with its associated conditional QoS parameter set, or it may be broadcast over MCCH in the cell.

In certain example embodiments, UE <NUM> may be configured with the one more conditional QoS parameter sets either for one MBS session or applicable for multiple sessions. If configured for more than one MBS session, the applicability of the conditional QoS parameter set may be associated with a priority threshold of the MBS session (e.g., apply the conditional QoS parameter set only for MBS sessions of priority higher than <NUM>).

In some example embodiments, NE <NUM> may broadcast a congestion indicator such that when the congestion indicator is set to "TRUE," all UEs (e.g., UE <NUM>) which have been configured with any conditional QoS parameter sets apply them as described above. Alternatively, when the congestion indicator is set to 'FALSE,' or not broadcasted, UE <NUM> may disregard any conditional QoS parameter sets.

<FIG> illustrates an example of a signaling diagram for using SDT by RRC_INACTIVE UEs to give QoS information to a gNB. NE <NUM> and UE <NUM> may be similar to NE <NUM> and UE <NUM>, as illustrated in <FIG>, according to certain example embodiments. <FIG> is a variation of the embodiments described in <FIG>. Depending on specific threshold values that UE <NUM> is monitoring, UE <NUM> may either remain in RRC_INACTIVE state and use SDT to notify NE <NUM> of the QoS value and degraded reception quality, or switch to RRC_CONNECTED state. NE <NUM> and UE <NUM> may both be configured to support SDT.

At <NUM>, NE <NUM> may configure UE <NUM> with a QoS threshold (e.g., ID<NUM>).

At <NUM>, UE <NUM> may transition into, or already be in, an RRC_INACTIVE state.

At <NUM>, UE <NUM> may measure QoS, and determine that QoS is less than the QoS threshold (e.g., ID<NUM>).

At <NUM>, UE <NUM> may transmit to NE <NUM> a QoS degradation status (e.g., QoS value) using UL SDT data/signal, which may indicate the degrading quality of MBS reception. As an example, UE <NUM> may follow the SDT set-up procedure with NE <NUM> using either RACH (configured via system information) or over Type <NUM> CG resources (configured via dedicated signalling in RRCRelease).

At <NUM>, NE <NUM> may take appropriate measures (e.g., set a more conservative modulation and coding scheme (MCS) or increase the power for the transmission), and/or switch UE <NUM> to RRC_CONNECTED state to improve UE QoS.

In certain example embodiments, UE <NUM> may also define multiple threshold levels so that, depending on the threshold value, UE <NUM> may decide to either send SDT or go to RRC_CONNECTED mode. For example, if the reception quality is below Th_sdt, but above Th_connect, UE <NUM> may remain in RRC_INACTIVE state, and send QoS information to NE <NUM> using SDT. If quality/QoS degrades further and reaches below Th_connect, UE <NUM> may initiate RRC_CONNECTED state using RRCResumeRequest.

<FIG> illustrates an example of a flow diagram for defining one or multiple MBS sessions, and multiple threshold levels, for a QoS parameter and applicable time windows that may be performed by a UE, such as UE <NUM> illustrated in <FIG>, according to various example embodiments.

At <NUM>, the method may include receiving, from the NE, a configuration with multiple levels of QoS thresholds (i.e., ID<NUM>, ID<NUM>, ID<NUM>,. ), for example, Th_high (represented by ID<NUM>) and Th_low (represented by ID<NUM>), where Th_high > Th_low. The QoS thresholds may also set different parameters; for example, Th_high may contain delay and average throughput conditions. At <NUM>, the method may include entering, or already be in, an RRC_INACTIVE state.

At <NUM>, the method may include, based upon network conditions (e.g., load, congestion), receiving a broadcast from the NE to use one of the threshold values by broadcasting the ID of the threshold rather than the threshold itself. For example, if the NE is experiencing high congestion, the NE may notify via broadcast (e.g., via SIB/MCCH) the RRC_INACTIVE UEs to use Th_low by broadcasting the ID associated with Th_low, such that only a few of the RRC_INACTIVE UEs that are experiencing severe QoS degradation conditions may enable switching to RRC_CONNECTED state.

In certain example embodiments, the UE may receive a broadcast over MCCH "threshold levels" that the UE receiving the MBS session in RRC_INACTIVE state should follow, rather than broadcasting the threshold via dedicated signaling. This may occur since the UE may constantly monitor the threshold levels over MCCH to determine whether they have been fulfilled.

In some example embodiments, the UE may be configured with one or more threshold values on a per cell basis and/or configure each threshold value for one or multiple MBS sessions. If configured for multiple MBS sessions, the threshold level may be applied based upon a priority threshold of the MBS session (i.e., apply the threshold parameter only for MBS sessions of priority higher than <NUM>).

In various example embodiments, the method may include receiving a broadcast of a congestion indicator, such that when the congestion indicator is set to "TRUE," all UEs which have been configured with threshold levels apply them, as described above. However, when the congestion indicator is set to 'FALSE,' or not broadcasted, the threshold level parameters are not used by the UE.

At <NUM>, the method may include setting ID<NUM> as the QoS threshold level. At <NUM>, the method may include measuring that QoS is more than ID<NUM>. As a result, the UE may remain in RRC_INACTIVE state. At <NUM>, the method may include measuring QoS again, and determine that QoS is less than ID<NUM>. At <NUM>, the method may include transmitting to the NE an RRCResumeRequest.

<FIG> illustrates an example of a flow diagram of a method for defining one or multiple MBS sessions, and multiple threshold levels, for a QoS parameter and applicable time windows that may be performed by a NE, such as NE <NUM> illustrated in <FIG>, according to various example embodiments.

In general, one QoS threshold level may be defined for RRC_INACTIVE UEs, such as a UE, such as UE <NUM> illustrated in <FIG>. Thus, whenever the UE experiences QoS less than a threshold level, the UE may switch to RRC_CONNECTED state. Multiple QoS threshold values may be defined/configured by the NE for UEs receiving in RRC_INACTIVE state.

At <NUM>, the method may include configuring the UE with multiple levels of QoS thresholds (i.e., ID<NUM>, ID<NUM>, ID<NUM>,. ), for example, Th_high (represented by ID<NUM>) and Th_low (represented by ID<NUM>), where Th_high > Th_low. The QoS thresholds may also set different parameters; for example, Th_high may contain delay and average throughput conditions. At <NUM>, the method may include determining that a high level of network congestion is occurring, and decide to use one of the QoS thresholds (e.g., Th_low, ID<NUM>), and allow a limited number of UEs that are experiencing severe QoS degradation to switch to RRC_CONNECTED state.

At <NUM>, the method may include, based upon network conditions (e.g., load, congestion), broadcasting to all UEs, including the UE, to use one of the threshold values including the ID of the threshold rather than the threshold itself. For example, if the NE is experiencing high congestion, the NE may notify via broadcast (e.g., via SIB/MCCH) the RRC_INACTIVE UEs to use Th_low by broadcasting the ID associated with Th_low, such that only a few of the RRC_INACTIVE UEs that are experiencing severe QoS degradation conditions may enable switching to RRC_CONNECTED state.

In certain example embodiments, the NE may directly broadcast over MCCH "threshold levels" that UEs (e.g., the UE) receiving the MBS session in RRC_INACTIVE state should follow, rather than broadcasting the threshold via dedicated signaling. This may occur since the UE may constantly monitor the threshold levels over MCCH to determine whether they have been fulfilled.

In some example embodiments, the method may include configuring the UEs (e.g., the UE) with one or more threshold values on a per cell basis and/or configure each threshold value for one or multiple MBS sessions. If configured for multiple MBS sessions, the threshold level may be applied based upon a priority threshold of the MBS session (i.e., apply the threshold parameter only for MBS sessions of priority higher than <NUM>).

In various example embodiments, the method may include receiving a congestion indicator, such that when the congestion indicator is set to "TRUE," all UEs which have been configured with threshold levels apply them, as described above. However, when the congestion indicator is set to 'FALSE,' or not broadcasted, the threshold level parameters are not used by the UE.

At <NUM>, the method may include receiving from the UE an RRCResumeRequest.

At <NUM>, the method may include determining that network congestion occurring has fallen below a certain lower level, and decide to use another of the less-stringent QoS thresholds (e.g., Th_high, ID<NUM>).

At <NUM>, based upon network conditions (e.g., load, congestion), the method may include broadcasting to all UEs to use a less-stringent threshold value by broadcasting the ID of the threshold. This may enable more UEs (e.g., severe and less severe) to resume RRC_CONNECTED state.

At <NUM>, the method may include receiving an RRCResumeRequest.

<FIG> illustrates an example of a flow diagram of a method for defining one or multiple MBS sessions, and multiple threshold levels, for a QoS parameter and applicable time windows that may be performed by a UE, such as UE <NUM> illustrated in <FIG>, according to various example embodiments. Multiple QoS threshold values may be defined/configured by a NE, such as NE <NUM> illustrated in <FIG>, for UEs receiving in RRC_INACTIVE state. Based on the time period, the UE may apply the appropriate threshold values; thus, there is no need for the NE to broadcast new thresholds each time there is a change in congestion levels.

At <NUM>, the method may include receiving multiple levels of QoS thresholds for different time windows (e.g., ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>; ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>). At <NUM>, the method may include transitioning to, or already being in, an RRC_INACTIVE state.

At <NUM>, the method may include setting ID<NUM> as a QoS threshold level with a specified time window.

At <NUM>, when the time is between T<NUM>-T<NUM>, the method may include monitoring that QoS is more than ID<NUM>. Thus, the UE may remain in RRC_INACTIVE state.

At <NUM>, the method may include determining that QoS has fallen below ID1.

At <NUM>, the method may include transmitting to the NE an RRCResumeRequest.

At <NUM>, the method may include setting ID<NUM> (e.g., threshold level <NUM> in time T<NUM> - T<NUM>) as the QoS threshold level.

At <NUM>, the method may include determining that QoS has fallen below ID<NUM>.

<FIG> illustrates an example of a flow diagram of a method that may be performed by a NE, such as NE <NUM> illustrated in <FIG>, according to various example embodiments. Multiple QoS threshold values may be defined/configured by the NE for UEs, such as UE <NUM> illustrated in <FIG>, receiving in RRC_INACTIVE state. Based on the time period, the UE may apply the appropriate threshold values; thus, there is no need for the NE to broadcast new thresholds each time there is a change in congestion levels.

At <NUM>, the method may include configuring the UE with multiple levels of QoS thresholds for different time windows (e.g., ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>; ID<NUM> for threshold <NUM> and time window T<NUM> - T<NUM>).

In various example embodiments, the NE may predict different congestion levels (e.g., high: radio congestion level is above <NUM>%; moderate: radio congestion level is <NUM>-<NUM>%; low: radio congestion level is below <NUM>%) at different peak hours (e.g., T<NUM>, T<NUM>, T<NUM>,. Based on internal algorithms, the NE may be configured to predict different congestion levels at different time periods, and accordingly, derive the optimized QoS threshold levels, which may be configured at the UE. The predictions may be derived statistically and/or obtained from a SON/automation/AI/ML network functions/modules that are available (e.g., NWDAF). Similarly, the NE may derive non-peak hours and/or optimized threshold levels application within various time windows. By configuring the UE with these values, the NE does not need to broadcast new thresholds during peak/non-peak hours, and the UE may apply the configured thresholds during the time window.

<FIG> illustrates an example of a flow diagram of a method for defining one or multiple MBS sessions, and optionally one or more conditional QoS parameter sets, and applicable time windows that may be performed by a UE, such as UE <NUM> illustrated in <FIG>, according to various example embodiments.

At <NUM>, the method may include receiving, from a NE, such as NE <NUM> illustrated in <FIG>, one or more conditional QoS parameter sets, wherein each QoS parameter set may be associated with an ID (e.g., parameter set <NUM> with ID<NUM> should be used at time window T<NUM> (if applied); parameter set <NUM> with ID<NUM> should be used at time window T<NUM>). Each conditional QoS parameter set may include a set of QoS parameters, such that if any QoS parameter is not fulfilled, the method may include reconnecting, as described in <FIG> or <FIG>, and/or send an indication over SDT using the techniques described in <FIG> (discussed above). At <NUM>, the method may include transitioning to, or already be in, an RRC_INACTIVE state, and be receiving MBS data.

At <NUM>, the method may include receiving over SIB/MCCH which conditional parameter set IDs the UE should apply in a given cell at a given point in time. If the NE uses a dedicated configuration for RRC_INACTIVE UEs, it may configure ID<NUM> with the selected time window (if applicable) in the UE when the UE was in RRC_CONNECTED state.

At <NUM>, the method may include measuring the parameters in ID<NUM> and/or ID<NUM>, and check whether all parameter conditions are met. For example, an RRC_INACTIVE UE may constantly monitor the conditional QoS parameters sets according to the ID broadcast over MCCH, and possibly the current time to check whether all parameters are fulfilled.

At <NUM>, if the UE determines that ID<NUM> and/or ID<NUM> parameter conditions are satisfied, the method may include remaining in RRC_INACTIVE state. If all the parameter conditions are fulfilled, the UE may continue to receive the MBS data in RRC_INACTIVE state. Alternatively, if at <NUM> the UE determines that ID<NUM> and/or ID<NUM> parameter conditions are not satisfied, at <NUM>, the method may include transmitting to the NE an RRCResumeRequest, or use SDT to notify the NE of the QoS level/value. If any of QoS conditions are not fulfilled, the UE may reconnect as discussed in <FIG> or <FIG>, and/or send an indication over SDT using techniques in <FIG>.

In certain example embodiments, the method may include receiving over MCCH conditional QoS parameter sets which the UE (receiving the MBS session in RRC_INACTIVE state, from <NUM>) should follow. These conditional QoS parameters sets may include a set of QoS parameters, such that if any of them are not fulfilled, the UE may reconnect as described in <FIG>, and/or send an indication over SDT the techniques described in <FIG>. The UE may constantly monitor the conditional QoS parameters sets broadcast over MCCH to check whether all parameters are fulfilled.

In various example embodiments, the NE may associate a time window with any of the conditional QoS parameter sets. For example, at a given point in time, the UE may only consider the conditional QoS parameters sets if the current time falls within the time window. The time window may either be configured in the UE, together with its associated conditional QoS parameter set, or it may be broadcast over MCCH in the cell.

In certain example embodiments, the UE may be configured with the one more conditional QoS parameter sets either for one MBS session or applicable for multiple sessions. If configured for more than one MBS session, the applicability of the conditional QoS parameter set may be associated with a priority threshold of the MBS session (e.g., apply the conditional QoS parameter set only for MBS sessions of priority higher than <NUM>).

In some example embodiments, the NE may broadcast a congestion indicator such that when the congestion indicator is set to "TRUE," all UEs (e.g., the UE) which have been configured with any conditional QoS parameter sets apply them as described above. Alternatively, when the congestion indicator is set to 'FALSE,' or not broadcasted, the UE may disregard any conditional QoS parameter sets.

<FIG> illustrates an example of a flow diagram of a method for defining one or multiple MBS sessions, and optionally one or more conditional QoS parameter sets, and applicable time windows that may be performed by a NE, such as NE <NUM> illustrated in <FIG>, according to various example embodiments.

At <NUM>, the method may include configuring a UE, such as UE <NUM> illustrated in <FIG>, with one or more conditional QoS parameter sets, wherein each QoS parameter set may be associated with an ID (e.g., parameter set <NUM> with ID<NUM> should be used at time window T<NUM> (if applied); parameter set <NUM> with ID<NUM> should be used at time window T<NUM>). Each conditional QoS parameter set may include a set of QoS parameters, such that if any QoS parameter is not fulfilled, the UE may reconnect, as described in <FIG> or <FIG>, and/or send an indication over SDT using the techniques described in <FIG> (discussed below).

At <NUM>, the method may include broadcasting over SIB/MCCH which conditional parameter set IDs the UE should apply in a given cell at a given point in time. If the NE uses a dedicated configuration for RRC_INACTIVE UEs, it may configure ID<NUM> with the selected time window (if applicable) in the UE when the UE was in RRC_CONNECTED state.

If the UE determines that ID<NUM> and/or ID<NUM> parameter conditions are not satisfied, the method may include, at <NUM>, receiving an RRCResumeRequest, or use SDT to notify the NE.

In certain example embodiments, the NE may directly broadcast over MCCH conditional QoS parameter sets which the UE (receiving the MBS session in RRC_INACTIVE state) should follow. These conditional QoS parameters sets may include a set of QoS parameters, such that if any of them are not fulfilled, the UE may reconnect as described in <FIG>, and/or send an indication over SDT the techniques described in <FIG>. The UE may constantly monitor the conditional QoS parameters sets broadcast over MCCH to check whether all parameters are fulfilled.

In some example embodiments, the NE may broadcast a congestion indicator such that when the congestion indicator is set to "TRUE," all UEs which have been configured with any conditional QoS parameter sets apply them as described above. Alternatively, when the congestion indicator is set to 'FALSE,' or not broadcasted, the UE may disregard any conditional QoS parameter sets.

<FIG> illustrates an example of a flow diagram of a method for using SDT by RRC_INACTIVE UEs to give QoS information to a gNB that may be performed by a UE, such as UE <NUM> illustrated in <FIG>, according to various example embodiments. Depending on specific threshold values that the UE is monitoring, the UE may either remain in RRC_INACTIVE state and use SDT to notify a NE, such as NE <NUM> illustrated in <FIG>, of the QoS value and degraded reception quality, or switch to CONNECTED mode about degraded reception quality. The UE and NE may both be configured to support SDT.

At <NUM>, the method may include receiving, from the NE, a QoS threshold (e.g., ID<NUM>) configuration.

At <NUM>, the method may include transitioning into, or already being in, an RRC_INACTIVE state.

At <NUM>, the method may include measuring QoS, and determining that QoS is less than the QoS threshold (e.g., ID<NUM>).

At <NUM>, the method may include transmitting to the NE a QoS degradation status (e.g., QoS value) using UL SDT data/signal, which may indicate the degrading quality of MBS reception. As an example, the UE may follow the SDT set-up procedure with the NE using either RACH (configured via system information) or over Type <NUM> CG resources (configured via dedicated signalling in RRCRelease).

At <NUM>, the method may include taking appropriate measures (e.g., set a more conservative MCS or increase the power for the transmission), and/or switching the UE to RRC_CONNECTED state to improve UE QoS.

In certain example embodiments, the UE may also define multiple threshold levels so that depending on the threshold value, the UE may decide to either send SDT or go to RRC_CONNECTED mode. For example, if the reception quality is below Th_sdt, but above Th_connect, the UE may remain in RRC_INACTIVE state, and send QoS information to the NE using SDT. If quality/QoS degrades further and reaches below Th_connect, the UE may initiate RRC_CONNECTED state using RRCResumeRequest. Whenever the UE determines that reception quality is below Th_sdt, instead of directly switching to RRC_CONNECTED state, the UE may send SDT data/signal to the NE, and indicate its QoS state/value.

<FIG> illustrates an example of a flow diagram of a method that may be performed by a NE, such as NE <NUM> illustrated in <FIG>, according to various example embodiments. Depending on specific threshold values that a UE, such as UE <NUM> illustrated in <FIG>, is monitoring, the UE may either use SDT or switch to CONNECTED mode to inform the NE about degraded reception quality. The NE and UE may both be configured to support SDT.

At <NUM>, the method may include configuring the UE with a QoS threshold (e.g., ID<NUM>).

At <NUM>, the method may include receiving a QoS degradation status (e.g., QoS value) using UL SDT data/signal, which may indicate the degrading quality of MBS reception. As an example, the UE may follow the SDT set-up procedure with the NE using either RACH (configured via system information) or over Type <NUM> CG resources (configured via dedicated signalling in RRCRelease).

In certain example embodiments, the UE may also define multiple threshold levels so that depending on the threshold value, the UE may decide to either send SDT or go to RRC_CONNECTED mode. For example, if the reception quality is below Th_sdt, but above Th_connect, the UE may remain in RRC_INACTIVE state, and send QoS information to the NE using SDT. If quality/QoS degrades further and reaches below Th_connect, the UE may initiate RRC_CONNECTED state using RRCResumeRequest. Whenever the UE determines that reception quality is below a threshold, instead of directly switching to RRC_CONNECTED state, the UE may send SDT data/signal to the NE, and indicate its QoS state/value.

<FIG> illustrates an example of a system according to certain example embodiments. In one example embodiment, a system may include multiple devices, such as, for example, NE <NUM> and/or UE <NUM>.

NE <NUM> may be one or more of a base station (e.g., <NUM> UMTS NodeB, <NUM> LTE Evolved NodeB, or <NUM> NR Next Generation NodeB), a serving gateway, a server, and/or any other access node or combination thereof.

NE <NUM> may further comprise at least one gNB-centralized unit (CU), which may be associated with at least one gNB-distributed unit (DU). The at least one gNB-CU and the at least one gNB-DU may be in communication via at least one F1 interface, at least one Xn-C interface, and/or at least one NG interface via a <NUM>th generation core (5GC).

UE <NUM> may include one or more of a mobile device, such as a mobile phone, smart phone, personal digital assistant (PDA), tablet, or portable media player, digital camera, pocket video camera, video game console, navigation unit, such as a global positioning system (GPS) device, desktop or laptop computer, single-location device, such as a sensor or smart meter, or any combination thereof. Furthermore, NE <NUM> and/or UE <NUM> may be one or more of a citizens broadband radio service device (CBSD).

NE <NUM> and/or UE <NUM> may include at least one processor, respectively indicated as <NUM> and <NUM>. Processors <NUM> and <NUM> may be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors may be implemented as a single controller, or a plurality of controllers or processors.

At least one memory may be provided in one or more of the devices, as indicated at <NUM> and <NUM>. The memory may be fixed or removable. The memory may include computer program instructions or computer code contained therein. Memories <NUM> and <NUM> may independently be any suitable storage device, such as a non-transitory computer-readable medium. The term "non-transitory," as used herein, may correspond to a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., random access memory (RAM) vs. read-only memory (ROM)). A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory, and which may be processed by the processors, may be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

Processors <NUM> and <NUM>, memories <NUM> and <NUM>, and any subset thereof, may be configured to provide means corresponding to the various blocks of <FIG>. Although not shown, the devices may also include positioning hardware, such as GPS or micro electrical mechanical system (MEMS) hardware, which may be used to determine a location of the device. Other sensors are also permitted, and may be configured to determine location, elevation, velocity, orientation, and so forth, such as barometers, compasses, and the like.

As shown in <FIG>, transceivers <NUM> and <NUM> may be provided, and one or more devices may also include at least one antenna, respectively illustrated as <NUM> and <NUM>. The device may have many antennas, such as an array of antennas configured for multiple input multiple output (MIMO) communications, or multiple antennas for multiple RATs. Other configurations of these devices, for example, may be provided. Transceivers <NUM> and <NUM> may be a transmitter, a receiver, both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception.

The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus, such as UE, to perform any of the processes described above (i.e., <FIG>). Therefore, in certain example embodiments, a non-transitory computer-readable medium may be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain example embodiments may be performed entirely in hardware.

In certain example embodiments, an apparatus may include circuitry configured to perform any of the processes or functions illustrated in <FIG>. As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry), (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions), and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

<FIG> illustrates an example of a <NUM> network and system architecture according to certain example embodiments. Shown are multiple network functions that may be implemented as software operating as part of a network device or dedicated hardware, as a network device itself or dedicated hardware, or as a virtual function operating as a network device or dedicated hardware. The NE and UE illustrated in <FIG> may be similar to NE <NUM> and UE <NUM>, respectively. The user plane function (UPF) may provide services such as intra-RAT and inter-RAT mobility, routing and forwarding of data packets, inspection of packets, user plane QoS processing, buffering of downlink packets, and/or triggering of downlink data notifications. The application function (AF) may primarily interface with the core network to facilitate application usage of traffic routing and interact with the policy framework.

According to certain example embodiments, processors <NUM> and <NUM>, and memories <NUM> and <NUM>, may be included in or may form a part of processing circuitry or control circuitry. In addition, in some example embodiments, transceivers <NUM> and <NUM> may be included in or may form a part of transceiving circuitry.

In some example embodiments, an apparatus (e.g., NE <NUM> and/or UE <NUM>) may include means for performing a method, a process, or any of the variants discussed herein. Examples of the means may include one or more processors, memory, controllers, transmitters, receivers, and/or computer program code for causing the performance of the operations.

In various example embodiments, apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to transmit, to a user equipment, more than one quality of service threshold configuration each comprising at least one quality of service threshold. Each of the quality of service threshold configuration may be associated with a quality of service threshold configuration identifier.

Certain example embodiments may be directed to an apparatus that includes means for performing any of the methods described herein including, for example, means for transmitting, to a user equipment, more than one quality of service threshold configuration each comprising at least one quality of service threshold. Each of the quality of service threshold configurations may be associated with a quality of service threshold configuration identifier.

In various example embodiments, apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to receive, from a network entity, more than one quality of service threshold configuration each comprising at least one quality of service threshold; receive, from the network entity, one of the quality of service threshold configuration identifiers; measure a quality of service for each of the quality of service thresholds of the quality of service threshold configuration associated with the received quality of service threshold configuration identifier; and determine a radio resource control state based upon a comparison of the measured quality of service being above or below a respective quality of service threshold of each of the quality of service thresholds of the quality of service threshold configuration associated with the received quality of service threshold configuration identifier. Each of the quality of service threshold configurations may be associated with a quality of service threshold configuration identifier.

Certain example embodiments may be directed to an apparatus that includes means for performing any of the methods described herein including, for example, means for receiving, from a network entity, more than one quality of service threshold configuration each comprising at least one quality of service threshold; means for receiving, from the network entity, one of the quality of service threshold configuration identifiers; means for measuring a quality of service for each of the quality of service thresholds of the quality of service threshold configuration associated with the received quality of service threshold configuration identifier; and determining a radio resource control state based upon a comparison of the measured quality of service being above or below a respective quality of service threshold of each of the quality of service thresholds of the quality of service threshold configuration associated with the received quality of service threshold configuration identifier. Each of the quality of service threshold configurations may be associated with a quality of service threshold configuration identifier.

For example, the usage of the phrases "various embodiments," "certain embodiments," "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an example embodiment may be included in at least one example embodiment. Thus, appearances of the phrases "in various embodiments," "in certain embodiments," "in some embodiments," or other similar language throughout this specification does not necessarily all refer to the same group of example embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments.

As used herein, "at least one of the following: <a list of two or more elements>" and "at least one of <a list of two or more elements>" and similar wording, where the list of two or more elements are joined by "and" or "or," mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

Additionally, if desired, the different functions or procedures discussed above may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the description above should be considered as illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

Claim 1:
An apparatus, comprising:
means for transmitting (<NUM>, <NUM>, <NUM>), to a user equipment, more than one quality of service threshold configuration each comprising at least one quality of service threshold in order to configure the user equipment with multiple levels of quality of service thresholds, wherein each of the quality of service threshold configurations are associated with a quality of service threshold configuration identifier.