Methods, products, and apparatuses for handling master cell group, MCG, failure and radio link failure, RLF, reporting

Abstract

A method (400) for reporting radio link failure, RLF, information. The method includes a user equipment, UE, detecting (s402) an RLF with respect to a master cell group, MCG. The method also includes, in response to detecting the RLF with respect to the MCG, the UE storing (s404) RLF information. The method also includes the UE transmitting (s406) a first message containing MCG failure information (e.g., the RLF information) and activating a timer. The method also includes, after transmitting the first message and activating the timer, the UE receiving (s408) a second message. The method also includes, in response to receiving the second message, the UE determining (s410) that a condition is satisfied, where determining that the condition is satisfied includes determining at least that the timer is still running. The method also includes, as a result of determining that the condition is satisfied, the UE deleting (s412) the RLF information.

Description

Technical Field

[0001] Examples involving MCG fault reporting and RLF fault reporting are disclosed. Background Technology

[0002] 1.1-5G Architecture

[0003] The current 5G Radio Access Network (RAN) (Next Generation RAN) architecture is described and illustrated in Technical Specification (TS) 38.401 v15.7.0 (www.3gpp.org / ftp / / Specs / archive / 38_series / 38.401 / 38401-f70.zip), such as... Figure 1 As shown.

[0004] The NG architecture can be further described as follows. NG-RAN consists of a collection of next-generation node Bs (gNBs) connected to the 5G core (5GC) via next-generation (NG) interfaces. gNBs can support Frequency Division Duplex (FDD), Time Division Duplex (TDD), or dual-mode operation. gNBs can be interconnected via the Xn interface. A gNB can consist of a gNB Central Unit (gNB-CU) and one or more gNB Distributed Units (gNB-DUs). gNB-CUs and gNB-DUs are connected via the F1 logical interface. One gNB-DU is connected to only one gNB-CU. For flexibility, a gNB-DU can be connected to multiple gNB-CUs through appropriate implementations. NG, Xn, and F1 are logical interfaces. NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture (i.e., the NG-RAN logical nodes and the interfaces between them) is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the associated TNL protocols and functionalities are specified. TNL provides services for user plane transport and signaling transport.

[0005] Another architectural option involves a Long Term Evolution (LTE) Evolved Node B (eNB) connected to the Evolved Packet Core Network (EPC) connecting to a so-called NR-gNB via an X2 interface. The latter is a gNB that is not directly connected to the core network (CN) but connects to the eNB via X2 solely for dual connectivity.

[0006] Figure 1The architecture can be extended by splitting the gNB-CU into two entities. One gNB-CU-User Plane (gNB-CU-UP) serves the user plane and takes over the Packet Data Convergence Protocol (PDCP), while one gNB-CU-CP serves the control plane and takes over the PDCP and Radio Resource Control (RRC) protocols. For completeness, it should be said that the gNB-DU takes over the Radio Link Control (RLC) / Media Access Control (MAC) / Physical Layer (PHY) protocols.

[0007] 1.2 Mobility Robustness Organization (MRO) and Radio Link Failure (RLF) in LTE / NR

[0008] Seamless handover is a key feature of 3GPP (3rd Generation Partnership Project) technologies. Successful handover ensures that user equipment (UE) (i.e., any device capable of wireless communication with an access point (e.g., gNB, eNB, etc.)) can move between different cell coverage areas without significant interruption in data transmission. However, there are scenarios where the network fails to hand over the UE to the 'correct' neighboring cell in a timely manner, and in such scenarios, the UE will assert a radio link failure (RLF) or a handover failure (HOF).

[0009] Once a HOF and RLF occur, the UE can take autonomous action, attempting to select a cell and initiate a reconnection procedure, ensuring the UE is trying to recover as quickly as possible so it can be reached again. An RLF will result in a poor user experience because the UE only asserts an RLF when it realizes there is no reliable communication channel (radio link) available between itself and the network. Furthermore, reconnection requires signaling with the newly selected cell (random access procedure, RRC reconnection request, RRC reconnection, RRC reconnection complete, RRC reconfiguration, and RRC reconfiguration complete), adding latency until the UE can exchange data with the network again.

[0010] According to the LTE / NR specifications (TS 36.331, TS 38.331), the possible causes of radio link failure are one of the following:

[0011] 1) Timer T310 related to radio link monitoring has expired;

[0012] 2) The timer T312 associated with the measurement report expired (no switchover command was received from the network during the duration of this timer, even though the measurement report was sent while T310 was running);

[0013] 3) Once the maximum number of RLC retransmissions for the MCG is reached; and

[0014] 4) Once a random access problem indication is received from the MCG MAC entity.

[0015] Because RLF (Rapid Regression Failure) triggers rebuilds (which degrade performance and user experience), understanding the cause of RLF and attempting to optimize mobility-related parameters (such as the triggering conditions for measurement reports) to avoid subsequent RLFs is in the network's interest. Until MRO-related reporting is standardized in the network, only the UE knows some information related to how radio quality appears during an RLF, which is the practical reason for asserting RLFs, etc. For the network to identify the cause of an RLF, it needs more information from the UE, as well as from neighboring base stations.

[0016] As part of the MRO solution in LTE, the RLF reporting procedure was introduced in the RRC specification in the Rel-9 RAN2 work. This has affected the RRC specification (TS36.331) in the sense that the UE records relevant information when an RLF occurs and later reports it to the target cell to which the UE has successfully connected (e.g., after re-establishment). That has also affected the gNodeB inter-interface, i.e., the X2AP specification (TS36.423), because the eNodeB receiving the RLF report may forward it to the eNodeB where the fault originated.

[0017] In LTE / NR, lower layers internally provide out-of-synchronization (OOS) and synchronization (IS) information to higher layers through the UE's physical layer. This information can then be used to apply RRC / Layer 3 (i.e., higher layer) filtering to assess radio link failures (RLF). Figure 2 The diagram in the image illustrates the procedure. Figure 2 This shows the procedures related to higher-layer RLF in LTE.

[0018] The RLF report generated by the UE has been enhanced with more details in subsequent versions. Based on the latest LTE RRC specification (3GPP TS 36.331V12.8.0), the measurements included in the measurement report are:

[0019] 1) Measurements of the previous serving cell (PCell) (e.g., Reference Received Power (RSRP) and Reference Received Quality (RSRQ)).

[0020] 2) Measurements of neighboring cells in different frequencies of different RATs (Universal Terrestrial Radio Access (UTRA), Evolved-UTRA (E-UTRA), Global System for Mobile Communications (GSM) Edge RAN (GERAN), Code Division Multiple Access (CDMA) 2000).

[0021] 3) Measurements associated with the Wireless LAN (WLAN) AP (Received Signal Strength Indicator (RSSI)).

[0022] 4) Measurements associated with Bluetooth beacons (RSSI).

[0023] 5) Location information (if available) (including location coordinates and velocity).

[0024] 6) The globally unique identifier of the previous serving cell (if available), otherwise the physical cell ID (PCI) and carrier frequency of the previous serving cell.

[0025] 7) PCell's tracking region code.

[0026] 8) The time elapsed since the last 'switch command' message was received.

[0027] 9) Cell Radio Network Temporary Identifier (C-RNTI) used in previously serving cells.

[0028] 10) Whether the UE is configured with a Quality of Service (QoS) Class Identifier (QCI) value of 1 for a Data Radio Bearer (DRB).

[0029] The detection and recording of RLF-related parameters are excerpted from Section 5.3.11.3 of the LTE RRC specification and are reproduced in the table below.

[0030]

[0031]

[0032]

[0033]

[0034] After asserting the RLF, the RLF report is logged, and once the UE selects a cell and successfully rebuilds, it includes an indication that an RLF report is available in the RRC rebuild completion message to inform the target cell of this availability. Then, upon receiving a UEInformationRequest message with the flag "rlf-ReportReq-r9", the UE should include the RLF report (stored in the UE variable VarRLF-Report as described above) in the UEInformationResponse message and send it to the network.

[0035] The UEInformationRequest and UEInformationResponse messages are described below.

[0036] The UEInformationRequest is a command used by the E-UTRAN to retrieve information from the UE. The signaling radio bearer used for this message is SRB1; the RLC-SAP is AM; the logical channel is DCCH; and the direction is from the E-UTRAN to the UE.

[0037] The following table shows the various UEInformationRequest messages:

[0038]

[0039]

[0040] UEInformationRequest Field Description -rach-ReportReq: This field indicates whether the UE should report information about the random access procedure.

[0041] UEInformationResponse

[0042] The UEInformationResponse message is used by the UE to transmit information requested by the E-UTRAN. The signaling radio bearer used for the UEInformationResponse is SRB1 or SRB2 (when containing recorded measurement information); RLC-SAP is AM; the logical channel is DCCH; and the direction is from the UE to the E-UTRAN.

[0043] The following table shows the various UEInformationResponse messages.

[0044]

[0045]

[0046]

[0047]

[0048]

[0049]

[0050]

[0051] Based on the content of the RLF report (such as the globally unique identifier of the previous serving cell where the fault originated), the cell where the UE is rebuilding can forward the RLF report to the previous serving cell. This forwarding of the RLF report is to help the original serving cell adjust handover-related parameters (such as the measurement report trigger threshold), because the original serving cell is the cell that previously had parameters associated with the UE configured that led to the RLF.

[0052] For this purpose, two different types of inter-node messages have been standardized in LTE: radio link failure indication and handover report (in 36.423REFERENCE).

[0053] The Radio Link Failure Indication (RLF) procedure is used to transmit information about RRC reconstruction attempts or received RLF reports between eNBs. This message is sent from the eNB where the UE is performing the reconstruction to the eNB that was the UE's previous serving cell.

[0054] 1.3 MCG Rapid Recovery Procedure

[0055] In LTE / NR rel-16, a fast MCG link recovery procedure was agreed upon. Fast MCG link recovery is an RRC procedure in which, once a radio link failure is detected on the MCG, the UE sends an MCG failure information message to the primary node (MN) via the secondary cell group (SCG) instead of triggering RRC reconstruction.

[0056] If a radio link failure is detected for the MCG and Fast MCG Link Recovery is configured, the UE triggers Fast MCG Link Recovery. Otherwise, the UE initiates an RRC connection re-establishment procedure. During Fast MCG Link Recovery, the UE suspends MCG transmission for all radio bearers and reports the failure to the MN via the MCG failure information message using the SCG branch of Split Signalling Radio Bearer (SRB) 1 or SRB3.

[0057] The UE includes measurement results available based on the current measurement configurations of both the MN and the secondary node (SN) in the MCG fault information message. Once a fast MCG link recovery is triggered, the UE maintains the current measurement configurations from both the MN and SN, and continues measurements based on the configurations from the MN and SN, where possible. If the UE does not receive an RRC reconfiguration message or an RRC release message within a specific time (determined by a timer called T316) after initiating a fast MCG link recovery, the UE initiates an RRC connection re-establishment procedure.

[0058] Upon receiving MCG fault information, the MN can send an RRC reconfiguration message or an RRC release message to the UE using the SCG branch of split SRB1 or SRB3. Upon receiving the RRC reconfiguration message (which includes `reconfigurationWithSync` if the MCG is NR, or `mobilityControlInfo` if the MCG is LTE), the UE resumes MCG transmission for all radio bearers. Upon receiving the RRC release message, the UE releases all radio bearers and configurations.

[0059] It has also been agreed that the network can send an inter-RAT handover (HO) command to the UE in response to MCG fault information. That is, when the MCG is NR (NR-DC, NE-DC), the UE can receive a MobilityFromNR command containing an embedded RRCConnectionReconfiguration message, which will be used to hand over the UE to LTE. If the MCG is LTE ((NG)EN-DC), the UE can receive a MobilityFromEUTRA command containing an embedded RRCReconfiguration message, which will be used to hand over the UE to NR.

[0060] The structure of the MCGFailureInformation message is shown below (see also 3GPP TS 38.331, V16.0.0 (hereinafter referred to as "TS 38.331")). It can be seen that this message contains several measurements of the UE (NR and LTE measurements, both based on the MN / SN measurement configuration).

[0061]

[0062]

[0063] The MCGFailureInformation message provides information about an NR MCG failure detected by the UE and has the following characteristics: Signaling Radio Bearer: SRB1; RLC-SAP: AM; Logical Channel: DCCH; Direction: UE to Network. The following table provides a description of the elements of this message.

[0064]

[0065] Detection of radio link failures

[0066] As specified in Section 5.3.10.3 of TS 38.331:

[0067]

[0068]

[0069]

[0070]

[0071]

[0072] Summary of the Invention

[0073] As discussed above, LTE / NRel-16 specifies a fast recovery procedure for the MCG, which means that when the UE detects an RLF (Recurrent Link Fault) related to the MCG, the UE will not initiate a reconstruction procedure. Instead, the UE will send an MCG fault information report to the MN using the SCG branch of split SRB1 or SRB3. According to the current procedure specified in Clause 5.3.10.3 of TS 38.331 (reprinted above), when a radio link fault is detected on the MCG, the UE generates an RLF report.

[0074] Therefore, even if the network has received an MCG fault (e.g., received an RRCConfiguration containing reconfigurationWithSync) and responded to it, the UE can still indicate the availability of an RLF report at the UE (e.g., in response to a received reconfiguration that has restored the MCG in an RRCReconfigurationComplete message). The network then sends a UE Information Request to request an RLF report, and the UE sends the RLF report in a UE Information Response message. This means that the UE reports the measurements related to the problem that led to the MCG fault recovery twice (first in the MCG fault information, and then in the RLF report to the network). In addition to sending the same measurement reports to the network twice, RLF reports are typically collected for SON / MDT purposes, aggregated, and analyzed for HO / mobility parameter tuning. Therefore, sending an RLF report for a recovered MCG fault can lead to some complications (e.g., the network unnecessarily / incorrectly changes parameter values, potentially increasing the chance of future RLF or handover failures).

[0075] Therefore, in one aspect, a method for reporting radio link failure (RLF) information is provided. The method includes: a user equipment (UE) detecting an RLF regarding a primary cell group (MCG). The method further includes: in response to detecting an RLF regarding an MCG, the UE storing the RLF information. The method further includes: the UE activating a timer and sending a first message containing MCG failure information (e.g., RLF information). The method further includes: after sending the first message and activating the timer, the UE receiving a second message. The method further includes: in response to receiving the second message, the UE determining that a condition is met, wherein determining that the condition is met includes at least determining that the timer is still running. The method further includes: as a result of determining that the condition is met, the UE deleting the RLF information.

[0076] In another aspect, a computer program containing instructions is provided, which, when executed by the processing circuitry of a UE, cause the UE to perform any of the methods disclosed herein. In one embodiment, a carrier containing a computer program is provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium. In another aspect, a UE configured to perform the methods disclosed herein is provided. The UE may include a memory and processing circuitry coupled to the memory.

[0077] The advantages of the above method include: 1) the UE will not report redundant measurement reports related to faults that have been recovered from the network, and 2) future complications / errors are prevented by not sending reports about problems that have been recovered from the network (to the nodes / functions handling MDT / SON). Attached Figure Description

[0078] Various embodiments are illustrated in the accompanying drawings, which are incorporated herein and form part of the specification.

[0079] Figure 1 An exemplary 5G RAN (NG-RAN) architecture is shown.

[0080] Figure 2 This shows the procedures related to higher-layer RLF in LTE.

[0081] Figure 3 This is a message flow diagram according to an embodiment.

[0082] Figure 4 This is a process according to some embodiments.

[0083] Figure 5 A UE according to some embodiments is shown. Detailed Implementation

[0084] 1. Sample implementation related to deleting RLF reports

[0085] 1.1 Remove RLF reports when an RRCReconfiguration containing reconfigurationWithSync is received.

[0086] 1.1.1 Delete in the reconfiguration and synchronization procedure

[0087] In one embodiment, the UE should perform the actions specified in the table below to perform reconfiguration and synchronization.

[0088]

[0089]

[0090]

[0091] 1.1.2 Delete in the reconfiguration procedure

[0092] In some rare cases, the `reconfigurationWithSync` procedure may execute successfully, but failures may occur when processing / compiling other information contained in the `RRCReconfiguration` message (e.g., reconfiguration failure). Therefore, an alternative is to wait until the complete message is ready to be sent before deleting the `RLF` report. Thus, in one embodiment, once `RRCReconfiguration` is received, or once conditional configuration (CHO or CPC) is performed, the UE performs the following actions:

[0093]

[0094] 1.2 Delete RLF report upon receiving RRCrease

[0095] In one embodiment, when the UE receives the RRRCrease message, the UE performs a procedure including the following operations: 1) stopping timer T380 (if it is running); 2) stopping timer T320 (if it is running); 3) determining whether timer T316 is running; 4) if it is determined that time is running, stepping the timer and clearing the information contained in the VarRLF-Report (if any).

[0096] 1.3 Delete RLF report upon receiving MobilityFromNR

[0097] In one embodiment, when the UE receives the MobilityFromNRCommand, the UE performs the following steps:

[0098]

[0099]

[0100] Since the current RRC specification already stores the RLF report in the UE's internal memory (e.g., in a UE variable named varRLF-Report, which is defined in section 7.4 of TS 38.331 as containing "RLF-report-r16" (also defined in TS 38.311) and PLMN-IdentityList), this disclosure proposes a set of methods when the UE asserts an MCG failure (the UE stores the RLF report, suspends the MCG, and then the UE sends an MCGFailureIndication message), wherein the UE can clear the information contained in the RLF report based on the result of the MCG failure recovery (e.g., delete the RLF report).

[0101] For example, in one embodiment, if the UE receives a `reconfigurationWithSync` message (within the `RRCReconfiguration` message) in response to an `MCGFailureInformation` message while the MCG is suspended, the UE clears the contents of the varRLF-Report. When this occurs, the UE follows conventional procedures such as stopping timer T316, performs actions related to the `reconfigurationWithSync` procedure, and resumes the MCG in the new PCell. We note that clearing the RLF report is only necessary after the reconfiguration and synchronization procedure (i.e., the handover command) has been successfully executed.

[0102] In another embodiment, if the UE receives an RCRelease message in response to an MCGFailureInformation message and while the MCG is suspended, the UE clears the contents of the varRLF-Report. When this occurs, the UE stops T316, performs the state transition to IDLE / INACTIVE as configured in the RCRelease message, and executes actions once transitioned to IDLE / INACTIVE.

[0103] In another embodiment, if the UE receives a MobilityFromNR / MobilityFromEUTRA message in response to MCGFailureInformation and while the MCG is suspended, the UE clears the contents of the varRLF-Report. When this occurs, the UE stops T316, performs the handover procedure-related actions configured in mobilityControlInfo / reconfigurationWithSync, and resumes the MCG in the new PCell in LTE / NR. We note that clearing the RLF report is only necessary after the reconfiguration and synchronization procedure (i.e., the handover command) has been successfully executed.

[0104] Figure 4 This is a flowchart illustrating a process 400 for reporting RLF information according to an embodiment. Process 400 may begin in step s402.

[0105] Step s402 includes UE 302 (see Figure 3 ) Detect RLF related to the main cell group (MCG).

[0106] Step s404 includes: after detecting an RLF, the UE generates and stores RLF information. For example, storing the RLF information includes storing the RLF information in the variable VarRLF-Report.

[0107] Step s406 includes: the UE activating a timer (e.g., timer T316) (i.e., the timer starts running and will expire (stop running) after a specific amount of time) and sending a first message 310 to the MCG master node (MN) 304 via the secondary node (SN) (see Figure 3 The first message 310 includes MCG fault information (e.g., RLF information).

[0108] Step s408 includes the UE receiving a second message 312 (e.g., sending a second message 312 in response to message 310).

[0109] Step s410 includes: in response to receiving the second message 312, the UE determines whether the condition is met, the determination including determining whether the timer is still running.

[0110] Step s412 includes: as a result of determining that a condition is met (e.g., as a result of determining that a timer is still running, or as a result of determining that time is still running and determining that the second message 312 is a specific message), the UE deletes the RLF information. In one embodiment, deleting the RLF information includes clearing the RLF-related information from the VarRLF-Report.

[0111] Step s414 (optional) includes deactivating (stopping) the UE timer.

[0112] In some embodiments, the second message 312 is one of the following messages: i) an RRCReconfiguration message with reconfigurationWithSync, ii) an RRCRelease message, iii) a MobilityFromNR message, iv) an RRCConnectionReconfigurationMessage with mobilityControlInfo, v) an RRCConnectionRelease message, or vi) a MobilityFromEUTRA message.

[0113] Figure 5 This is a block diagram of UE 302 according to some embodiments. For example... Figure 5 As shown, UE 302 may include: processing circuitry (PC) 502, which may include one or more processors (P) 555 (e.g., one or more general-purpose microprocessors and / or one or more other processors, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc.); communication circuitry 548, coupled to an antenna arrangement 549 including one or more antennas, and including a transmitter (Tx) 545 and a receiver (Rx) 547 to enable UE 302 to transmit and receive data (e.g., wirelessly transmit / receive data); and local storage unit (also known as a "data storage system") 508, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 502 includes a programmable processor, a computer program product (CPP) 541 may be provided. CPP 541 includes a computer-readable medium (CRM) 542 storing a computer program (CP) 543, which includes computer-readable instructions (CRI) 544. CRM 542 may be a non-transitory computer-readable medium, such as magnetic media (e.g., hard disk), optical media, memory devices (e.g., random access memory, flash memory), etc. In some embodiments, CRI 544 of computer program 543 is configured such that when executed by PC 502, CRI causes UE 302 to perform the steps described herein (e.g., the steps described herein with reference to the flowcharts). In other embodiments, UE 302 may be configured to perform the steps described herein without requiring code. That is, for example, PC 502 may consist of only one or more ASICs. Therefore, the features of the embodiments described herein may be implemented in hardware and / or software.

[0114] Overview of various embodiments

[0115] A1. A method for reporting RLF information 400 (see...) Figure 4 The method includes: a user equipment UE 302 detecting an RLF (Related Message Fault) regarding an MCG (Multi-Channel Group) in s402; in response to detecting the RLF regarding the MCG, the UE storing the RLF information in s404; the UE activating a timer and sending a first message 310 containing MCG fault information (e.g., RLF information) in s406; after sending the first message and activating the timer, the UE receiving a second message 312 in s408 (e.g., sending the second message 312 in response to the first message 310 (e.g., in response to the MCG fault information contained in the first message)); in response to receiving the second message 312, the UE determining that s410 satisfies a condition, wherein determining that the condition is satisfied includes at least determining that the timer (s410) is still running; and as a result of determining that the condition is satisfied, the UE deleting the RLF information in s412.

[0116] A2. The method of embodiment A1 further includes: in response to receiving the second message 312, the UE deactivates the s414 timer.

[0117] A3. The method of embodiment A1 or A2, wherein the second message 312 is one of the following messages: i) an RRCReconfiguration message with reconfigurationWithSync, ii) an RRCRelease message, iii) a MobilityFromNR message, iv) an RRCConnectionReconfigurationMessage with mobilityControlInfo, v) an RRCConnectionRelease message, or vi) a MobilityFromEUTRA message.

[0118] A4. The method of any of the above embodiments, wherein determining that the condition is met further includes the UE determining that the second message is an RRC message containing a reconfiguration and synchronization indicator (e.g., an RRCReconfiguration message containing a ReconfigurationWithSync information element (IE)), wherein, as a result of determining that the timer is still running and determining that the second message is an RRC message containing a reconfiguration and synchronization indicator, the UE performs the deletion step.

[0119] A5. A method of any of the embodiments A1-A3, wherein determining that the condition is met further includes the UE determining that the second message is a release message (e.g., RRCRelease message), wherein, as a result of determining that the timer is still running and determining that the second message is a release message, the UE performs the deletion step.

[0120] A6. A method of any of the embodiments A1-A3, wherein determining that the condition is met further includes the UE determining that the second message is one of the following messages: i) MobilityFromNR message, ii) RRCConnectionReconfigurationMessage with mobilityControlInfo, iii) RRCConnectionRelease message, or iv) MobilityFromEUTRA message, wherein, as a result of determining that the timer is still running and determining that the second message is one of i) MobilityFromNR message, ii) RRCConnectionReconfigurationMessage with mobilityControlInfo, iii) RRCConnectionRelease message, or iv) MobilityFromEUTRA message, the UE performs the deletion step.

[0121] B1. A computer program 543 comprising instructions 544, which, when executed by a processing circuit 502 of a user equipment UE 302, cause the UE 302 to perform the method of any of the above embodiments.

[0122] B2. A carrier comprising a computer program of embodiment B1, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium 542.

[0123] C1. A user equipment UE 302, the UE being adapted to perform the method of any of the embodiments described above.

[0124] D1. A user equipment UE 302, the UE comprising: processing circuitry 502; and a memory 542 containing instructions 544 executable by the processing circuitry, thereby enabling the UE to perform the methods of any of the embodiments described above.

[0125] E1. A method performed by a UE for reporting information related to a radio link failure (RLF). The UE operates in dual connectivity between a primary node (MN) and a secondary node (SN), wherein the MN provides a set of serving cells, namely the primary cell group (MCG), and the SN provides a set of serving cells, namely the secondary cell group (SCG). The method includes: 1) the UE detecting the RLF on the MCG; 2) the UE generating an RLF report and storing it; and 3) the UE initiating an MCG fault recovery procedure.

[0126] E2. The method of embodiment E1, wherein initiating the MCG fault recovery procedure includes: the UE starting timer T316; the UE preparing MCG fault information, including information about the cause of the fault and measurements taken at the time of the fault (in the serving cell and neighboring cells); and the UE sending the MCG fault information to the MN via the SN (using a secondary branch of split SRB1 or SRB3, if configured). After determining that the network has responded to the MCG fault information before T316 expires, the UE may delete the RLF report. In some embodiments, determining that the network has responded to the MCG fault information before T316 expires includes the UE receiving one of the following: A) if the MN is an NR node: i) an RRCReconfiguration message with reconfigurationWithSync, ii) an RRCRelease message, or iii) a MobilityFromNR message; or B) if the MN is an LTE node: i) an RRCConnectionReconfigurationMessage with mobilityControlInfo, ii) an RRCConnectionRelease message, or iii) a MobilityFromEUTRA message. In one alternative, the RLF report is deleted in all of the above situations (i.e., upon receiving a reconfiguration, release, or mobilityFromNR / mobilityFromEUTRA message). In another alternative, the RLF report is not deleted upon receiving a release message. In yet another alternative, the RLF report is not deleted upon receiving a mobilityFromNR / mobilityFromLTE message.

[0127] While various embodiments have been described herein, it should be understood that these embodiments have been presented merely as examples and not as limitations. Therefore, the breadth and scope of this disclosure should not be limited to any of the exemplary embodiments described above. Furthermore, unless otherwise indicated herein or otherwise clearly contradicted by the context, this disclosure covers any combination of the foregoing elements and all their possible variations.

[0128] Furthermore, although the processes described above and illustrated in the figures are shown as a sequence of steps, this is merely for illustrative purposes. Therefore, it is expected that some steps can be added, some steps can be omitted, the order of the steps can be rearranged, and some steps can be executed in parallel.

[0129] abbreviations

[0130] ACK confirmation

[0131] AP Application Protocol

[0132] BSR Buffer Status Report

[0133] BWP bandwidth portion

[0134] C-RNTI Cell Radio Network Temporary Identifier

[0135] CA carrier aggregation

[0136] CE control elements

[0137] CP control plane

[0138] CQI Channel Quality Indicator

[0139] DC dual connectivity

[0140] DCI Downlink Control Information

[0141] DL downlink

[0142] DRB Data Radio Bearer

[0143] eNB (EUTRAN) base station

[0144] E-RAB EUTRAN Radio Access Bearer

[0145] FDD Frequency Division Duplex

[0146] gNB NR base station

[0147] GTP-U GPRS Tunneling Protocol - User Plane

[0148] IP Internet Protocol

[0149] LTE Long Term Evolution

[0150] MCG Main Cell Group

[0151] MAC Media Access Control

[0152] MeNB main eNB

[0153] MgNB main gNB

[0154] MN master node

[0155] NACK (Negative Acknowledgment)

[0156] NR New Radio

[0157] PDCP (Packet Data Convergence Protocol)

[0158] PCell main cell

[0159] PCI Physical Cell Identifier

[0160] PSCell main SCell

[0161] PUSCH Physical Uplink Shared Channel

[0162] RLC Radio Link Control

[0163] RLF radio link failure

[0164] RRC Radio Resource Control

[0165] SCell Auxiliary Community

[0166] SCG Auxiliary Community Group

[0167] SCTP (Stream Control Transfer Protocol)

[0168] SeNB auxiliary eNB

[0169] SINR (Signal-to-Interference-plus-Noise Ratio)

[0170] SN auxiliary node

[0171] SR scheduling request

[0172] SRB signaling radio bearer

[0173] SUL supplements uplink

[0174] TDD (Time Division Duplex)

[0175] TEID (Tunnel Endpoint Identifier)

[0176] TNL Transport Network Layer

[0177] UCI uplink control information

[0178] UDP User Datagram Protocol

[0179] UE User Equipment

[0180] UL uplink

[0181] UP User Plane

[0182] URLLC Ultra-Reliable Low-Latency Communication

[0183] Interface between X2 base stations

Claims

1. A method (400) for reporting Radio Link Fault (RLF) information, the method comprising: User Equipment (UE) (302) detects (s402) RLF regarding Primary Cell Group (MCG); In response to the detection of the RLF regarding the MCG, the UE stores (s404) the RLF information; The UE sends (s406) a first message (310) containing MCG fault information and activates a timer; After sending the first message and activating the timer, the UE receives (s408) the second message (312). In response to receiving the second message (312), the UE determines (s410) that a condition is met, wherein determining that the condition is met includes at least determining that the timer is still running, and further includes the UE determining at least one of the following: - The second message is an RRC message containing reconfiguration and synchronization indicators; and - The second message is a MobilityFromEUTRA message or a MobilityFromNR message, or an RRCConnectionReconfigurationMessage with mobilityControlInfo; and As a result of determining that the conditions are met, the UE deletes (s412) the RLF information.

2. The method of claim 1, further comprising: In response to receiving the second message (312), the UE deactivates the timer (s414).

3. The method as described in claim 1 or 2, wherein, The second message (312) is one of the following: i) an RRCReconfiguration message with reconfigurationWithSync, ii) an RRCRelease message, iii) a MobilityFromNR message, or iv) an RRCConnectionRelease message.

4. The method as described in claim 1 or 2, wherein, Determining that the condition is met further includes: the UE determining that the second message is a release message, wherein, as a result of determining that the timer is still running and determining that the second message is a release message, the UE performs the deletion step.

5. The method as described in claim 1 or 2, wherein, Determining that the condition is met further includes: the UE determining that the second message is an RRCConnectionRelease message, wherein, as a result of determining that the timer is still running and determining that the second message is an RRCConnectionRelease message, the UE performs the deletion step.

6. The method as described in claim 1 or 2, wherein, The MCG fault information includes the RLF information.

7. A computer program product comprising instructions (544) that, when executed by a processing circuit (502) of a user equipment (UE) (302), cause the UE (302) to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium comprising a computer program, which, when executed by a processing circuitry (502) of a user equipment (UE) (302), causes the UE (302) to perform the method as described in any one of claims 1-6.

9. A user equipment (UE) (302), the UE comprising: Components used to detect (s402) radio link faults (RLFs) related to the main cell group (MCG); A component for storing (s404) RLF information in response to detecting the RLF regarding the MCG; The component used to activate the timer and send (s406) a first message (310) containing MCG fault information; A component for receiving (s408) the second message (312) after sending the first message and activating the timer; A component for determining (s410) whether a condition is met in response to receiving the second message (312), wherein determining whether the condition is met includes at least determining that the timer is still running, and further includes the UE determining at least one of the following: - The second message is an RRC message containing reconfiguration and synchronization indicators; and - The second message is a MobilityFromEUTRA message or a MobilityFromNR message, or an RRCConnectionReconfigurationMessage with mobilityControlInfo; and The component used to delete (s412) the RLF information as a result of determining that the conditions are met.

10. The UE of claim 9, further comprising: The component used to deactivate (s414) the timer in response to receiving the second message (312).

11. The UE as claimed in claim 9 or 10, wherein, The second message (312) is one of the following: i) an RRCReconfiguration message with reconfigurationWithSync, ii) an RRCRelease message, iii) a MobilityFromNR message, or iv) an RRCConnectionRelease message.

12. The UE as claimed in claim 9 or 10, wherein, Determining that the condition is met further includes: the UE determining that the second message is a release message, wherein, as a result of determining that the timer is still running and determining that the second message is a release message, the UE performs the deletion step.

13. The UE as claimed in claim 9 or 10, wherein, Determining that the condition is met further includes: the UE determining that the second message is an RRCConnectionRelease message, wherein, as a result of determining that the timer is still running and determining that the second message is an RRCConnectionRelease message, the UE performs the deletion step.

14. The UE as claimed in claim 9 or 10, wherein, The MCG fault information includes the RLF information.

15. A user equipment (UE) (302), the UE comprising: Processing circuit (502); as well as A memory (542) containing instructions (544) executable by the processing circuitry, thereby configuring the UE to perform the method as described in any one of claims 1-6.

Images