Apparatus for wireless communications system and user equipment

This application is a national phase under 35 U.S.C. § 371 of PCT International Application No. PCT/CN2020/086500 which has an International filing date of Apr. 23, 2020, the entire contents of each of which are hereby incorporated by reference.

The disclosure relates to an apparatus for a wireless communications system.

The disclosure further relates to a user equipment (UE).

The disclosure further relates to a method of operating an apparatus for a wireless communications system.

The disclosure further relates to a method of operating a user equipment.

Wireless communications systems may e.g. be used for wireless exchange of information between two or more entities.

The scope of protection sought for various embodiments of the disclosure is set out by the independent claims. The exemplary embodiments and features, if any, described in this specification, that do not fall under the scope of the independent claims, are to be interpreted as examples useful for understanding various exemplary embodiments of the disclosure.

Some embodiments relate to an apparatus for a wireless communications system, comprising at least one processor, and memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to configure a user equipment with a radio link control, RLC, failure configuration which defines how the user equipment should react to an RLC failure of a first logical channel associated with the user equipment.

In some embodiments, the apparatus or its functionality, respectively, may be provided in a network element of the communications systems, for example in a base station, e.g. a gNodeB (gNB).

In some embodiments, the apparatus according to the embodiments or its functionality, respectively, may be used for or within wireless communications systems based on or at least partially adhering to third generation partnership project, 3GPP, radio standards such as 4G E-UTRAN or 5G NR (fifth generation new radio). In some embodiments, the apparatus according to the embodiments or its functionality, respectively, may be used for a radio link failure (RLF), procedure of 5G NR-based communications systems.

As an example, one triggering condition for an RLF in a Uu interface as currently defined e.g. for 5G NR is characterized as follows: upon indication from a radio link control (RLC) layer that a maximum number of RLC retransmissions has been reached when using an RLC acknowledged mode (AM). According to this triggering condition, a maximal number of retransmissions in RLC is configured by using a parameter “maxRetxThreshold”, which is configured in the information element (IE) “RLC-Config”, as per 3GPP TS 38.331 (cf. e.g. 3GPP TS 38.331 V15.8.0 (2019-12)), and used by a transmitting side of an AM RLC entity to limit a total number of retransmissions of an RLC packet data unit (PDU). The detection of the RLF in this case may cause the UE to either transit to RRC_IDLE state or initiate a radio resource control (RRC) connection re-establishment procedure.

The maximal number of retransmissions parameter (i.e. maxRetxThreshold configured in RLC-Config) as currently defined e.g. for 5G NR applies to RLC AM as defined in 3GPP TS 38.331, where value t1 corresponds to 1 retransmission, value t2 corresponds to 2 retransmissions and so on. If the maximal number of retransmissions of an RLC entity is reached in an exemplary single cell scenario, a RLF will be declared, which will trigger the UE to re-establish the RRC connection with NW—as described above. More specifically, all radio bearers (RBs) except SRB0 will be suspended at the time when the RLF is declared. These suspended RBs (i.e., SRB2 and DRBs) can be resumed first upon receiving the first RRCReconfiguration message after the RRC connection re-establishment procedure is successfully completed. Thus, the user-plane data cannot be transmitted during the time when the DRBs are being resumed, thus causing an undesired interruption in the running applications.

As per TS 38.331, RLC-Config is comprised within the IE RLC-BearerConfig, which is used to configure an RLC entity and the corresponding logical channel (LCH) in MAC for uplink (besides the linking to a PDCP entity). Thus, distinct RLC entities can be configured for the UE (e.g. for different logical channels) and these can be configured differently, e.g. with different values for the maximal number of retransmissions.

In the current definition of RLF, as currently defined e.g. for 5G NR, a RLC failure for one logical channel/RLC entity (e.g., when reaching the maxRetxThreshold) implies the declaration of an RLF, and in turn, the suspending of all DRBs, which will interrupt the data transmission on any other DRB.

As an example, first, when an RLC failure happens, it could be due to a radio condition and/or protocol problems. In case of radio problems, it means that even RLC retransmissions cannot help recovering from radio losses. Although it can be expected that typically a radio link monitoring (RLM) procedure can detect a radio issue before an RLC failure happens, the RLM procedure as currently defined e.g. for 5G NR is limited to a primary cell (PCell). Thus, RLC failures may occur likely due radio problems on secondary cells (SCells) or due to a protocol failure (including a configuration issue), rather than a radio issue only on the PCell.

Besides, 5G NR also introduced a restriction of “allowed cells” an LCH can use which is different to legacy LTE in that an RLC failure for a LCH might only be a problem for those allowed cells for that LCH (e.g. if they are unlicensed cells, high frequency cells etc.) but should not impact other LCHs if they are using different cells with higher reliability/better channel quality.

This means that, according to some embodiments, an RLC failure of one RLC entity may not imply that another other logical channel cannot be supported adequately. This is an aspect which may be especially relevant when different service types with divergent quality of service (Qos) requirements coexist in a device. For example, achieving the maxRetxThreshold value from a logical channel used for a ultra-reliable and low-latency communication (URLLC) service should not necessarily trigger a suspension of logical channels with more relaxed QoS requirements, e.g. logical channels used to support massive machine type communication (mMTC) and/or enhanced mobile broadband (eMBB) services.

As a further example, secondly, the re-establishment that is triggered because of an RLC failure may be a comparatively slow procedure since it may include a cell selection (of the old or a new cell), a random-access procedure to the selected cell, with several RRC messages to be exchanged. In case of an RLC failure that is caused by protocol/configuration issues, a recovery attempt by the same cell (e.g. by reconfiguring the affected RLC entity) may be likely successful. But that would be initiated only after an unnecessary delay due to the re-establishment.

Some embodiments address aspects such as e.g. a method for handling RLC failures which aims at a faster recovery of an affected RLC entity (i.e. the RLC entity that detected the RLC failure(s)), while at the same time they may allow non-affected RLC entities to continue their service.

According to some embodiments, as already mentioned above, a user equipment may use the RLC failure configuration provided e.g. by configuration via the apparatus according to some embodiments to determine how to react to such RLC failure.

According to some embodiments, the RLC failure configuration defines whether the user equipment should notify the RLC failure of the first logical channel to a network.

According to some embodiments, the RLC failure configuration defines whether the user equipment should notify the RLC failure of the first logical channel to a network when at least a second logical channel associated with the user equipment operates normally, i.e. does not experience an RLC failure. According to some embodiments, this may enable to keep a normal, i.e. uninterrupted, operation for at least the second LCH and/or RB associated therewith, e.g. rather than declaring a RLF and initiating a re-establishment.

As an example, a second logical channel associated with the user equipment operates normally, e.g. when the second logical channel has not reached a predetermined number (e.g. a first threshold or the maximum RLC retransmission number) of RLC retransmissions.

According to some embodiments, the UE may be configured with multiple LCHs and/or RLC entities.

According to some embodiments, the UE may be configured with an individual RLC failure configuration per LCH, which enables to provide different LCHs with different RLC failure configurations.

According to some embodiments, the instructions, when executed by the at least one processor, further cause the apparatus to explicitly configure the user equipment with the RLC failure configuration.

According to some embodiments, the user equipment may also be configured implicitly with the RLC failure configuration.

According to some embodiments, which may e.g. be based on a multi-cell carrier aggregation (CA)/dual connectivity (DC) scenario, per-LCH configuring whether an RLC failure for an LCH should trigger an RLC failure report rather than re-establishment may be done implicitly, e.g. based on an allowed cell configuration for the LCH.

According to some embodiments, the implicit configuration may be part of the allowed cell configuration and may be enabled/disabled per UE. For instance, the configured cells that are allowed for a failed LCH, i.e. the first LCH, can be considered failed and may thus be suspended/deactivated, as long as there is at least another cell not failed and mapped to at least another LCH: under these conditions, according to some embodiments, an RLC failure report may be triggered without (RRC) re-establishment. According to some embodiments, otherwise, e.g. if any other cell is also failed or no other non-failed LCH is mapped to a cell, an RRC re-establishment is initiated.

In some embodiments, the allowed cells are unlicensed cells and/or high frequency cells (e.g., using the frequency range FR2 as e.g. defined by 3GPP 38.101-1, cf. e.g. 3GPP TS 38.101-1 V16.2.0 (2019-12), Table 5.1-1), since these may be more prone to radio errors. This ensures that problems on these cells will not impact other LCHs if they are using different cells with higher reliability/better channel quality.

In some embodiments, the RLC failure configuration comprises a first threshold, wherein the user equipment may determine, based on the first threshold, whether to transmit the RLC failure to a or the network.

In some embodiments, the first threshold is a predetermined number of RLC retransmissions.

According to some embodiments, which may e.g. be based on a single-cell scenario or a multi-cell CA/DC scenario, the first threshold may be seen as a new (additional) threshold in view of the existing threshold parameter “maxRetxThreshold”, which is configured in the information element (IE) “RLC-Config”, as per 3GPP TS 38.331 (cf. e.g. 3GPP TS 38.331 V15.8.0 (2019-12)).

According to some embodiments, the first (i.e., new) threshold may e.g. be denoted as “maxRetxThreshold_RLCReport” and may be configured to the UE to determine a) when (and/or whether) to report the RLC failure of the first LCH, for example if the current number of RLC AM retransmissions reaches the first threshold, and/or b) when (whether) to declare an RLF (e.g., if the current number of RLC AM retransmissions reaches the existing threshold parameter “maxRetxThreshold” defined for RLF detection).

According to some embodiments, the value of the first threshold “maxRetxThreshold_RLCReport” can be set lower than the existing “maxRetxThreshold”, e.g. to first trigger a report. According to some embodiments, this enables an attempt to first recover/solve an RLC failure issue, e.g. by reconfiguring of protocol parameters for the affected (first) LCH or changing the allowed cells and/or other LCP restrictions, before declaring an RLF and suspending all DRBS.

According to some embodiments, the RLC failure configuration comprises a first control information indicating to the user equipment whether to disable at least one mapping restriction.

According to some embodiments, which may e.g. be based on a single-cell scenario or a multi-cell CA/DC scenario, upon detecting that a given number of RLC AM retransmissions is reached for an RLC entity/LCH (corresponding e.g. to the maximum number defined for RLF detection (e.g., existing “maxRetxThreshold”) or to a lower configured number, e.g. the first threshold according to some embodiments explained above), if the LCH is configured with LCP (logical channel prioritization) mapping restrictions (e.g. according to allowedCG_list, allowedPriorityLevels, and allowedServingCells, cf. e.g. 3GPP TS 38.300 V15.8.0 (2019-12), e.g. chapter 16.1.2), the UE may disable at least one of those mapping restrictions (e.g., instead of triggering a RLF), which may be beneficial to get data to be transmitted through as soon as possible, and which may exemplarily be referred to as some actions of the “recovery behavior” according to some embodiments.

According to some embodiments the disabling of least one of those mapping restrictions may be performed automatically, i.e. without an explicit instruction to be received by the UE.

According to some embodiments, enabling this “recovery behavior” may depend on a network configuration. The configuration (e.g., in addition to the possible first threshold according to some embodiments explained above) may indicate which LCP mapping restrictions to disable (e.g., via an information element (IE) “RestrictionsDisableList”). For instance, according to some embodiments, after disabling a restriction according to “allowedServingCells”, the UE may fill an UL grant applicable to a cell previously restricted for the affected (e.g., first) LCH with data from that LCH. According to some embodiments, in turn, the presence of data of that LCH in the transmission corresponding to that grant may be implicitly indicative for the network that the UE has disabled the (LCP mapping) restriction, and in turn that the UE has experienced an RLC failure or the UE has reached the first threshold according to some embodiments explained above.

According to some embodiments, the first control information indicates which of a plurality of mapping restrictions to disable.

According to some embodiments, the RLC failure configuration comprises at least one priority threshold, wherein the user equipment may determine, based on the at least one priority threshold whether to transmit the RLC failure to a or the network.

According to some embodiments, the user equipment may determine, based on the at least one priority threshold and based on at least one of a) a lowest priority of logical channels associated with the user equipment, b) a priority of the first logical channel, whether to transmit the RLC failure to a or the network.

According to some embodiments, a first priority threshold and a second priority threshold may be provided.

According to some embodiments, which may e.g. be based on a single-cell scenario or a multi-cell CA/DC scenario, the UE may send an RLC failure report to the NW if the lowest priority of any existing logical channel is lower than the first configured threshold P1, and the priority of the LCH detecting RLC failure is higher than the second threshold P2. According to some embodiments, if another LCH with certain (i.e., non-vanishing) QoS difference and/or configuration difference comparing to the LCH detecting the RLC failure is configured, the RLC failure from the affected LCH (i.e. the one detecting the RLC failure) need not imply the failure of the other LCH and, thus, the other LCH should not be affected. Alternatively, according to some embodiments, it is configured per LCH or a priority threshold if a failure happens to an LCH with higher or lower priority than a configured threshold, RLC failure report is triggered.

According to some embodiments, the instructions, when executed by the at least one processor, further cause the apparatus to configure the user equipment, for example an LCH/RLC entity, with a second control information, for example a flag, indicating at least one of: a) the user equipment should declare a radio link failure upon detection of the RLC failure of the first logical channel, b) the user equipment should transmit the RLC failure of the first logical channel to the network, e.g. in the form of an RLC failure report, c) the user equipment should declare a radio link failure upon detection of an RLC failure of at least one other logical channel than the first logical channel, d) the user equipment should transmit the RLC failure report upon detection of an RLC failure of at least one other logical channel than the first logical channel.

According to some embodiments, the second control information, for example the flag, can be set considering the QoS requirements of the LCH/RLC entity and/or the set of configured LCH/RLC entities.

According to some embodiments, the instructions, when executed by the at least one processor, further cause the apparatus to set at least a part of the RLC failure configuration based on at least one user equipment specific condition.

According to some embodiments, the value of the first threshold and/or the conditions to declare a radio link failure and/or to send an RLF failure report can be set considering UE-specific conditions, e.g. the existing services in the UE and optionally also their Qos requirements. For instance, if both an eMBB service and a URLLC service coexist according to some embodiments, an RLC failure only from the URLLC service will not declare an RLF.

According to some embodiments, a or the first threshold and a second threshold may be configured, and the UE may send an RLC failure report to the NW if the highest value of the maximal number of retransmissions parameter (i.e. “maxRetxThreshold” configured in RLC-Config) as currently defined e.g. by 5G NR for an existing logical channel is higher than the first configured threshold, and the value of the “maxRetxThreshold” of the LCH detecting RLC failure is lower than the second configured threshold. In this option, the UE can ensure a large difference in terms of maxRetxThreshold between the declaring LCH (LCH that declares a RLF) and other LCHs. Thus, the RLC failure of the affect RLC entity should not affect the operation of another LCH.

According to some embodiments, the instructions, when executed by the at least one processor, further cause the apparatus to broadcast at least a part of the RLC failure configuration, for example at least one of: the first threshold, the second threshold.