Handling failures in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present invention discloses a method performed by a user equipment (UE) in a wireless communication system. The method comprises identifying whether the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC); in case that the UE supports the SCG failure information for the EN-DC or the NGEN-DC, setting an information element (IE) in the SCG failure information, wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC; and transmitting, to a network apparatus, the SCG failure information including the IE.

Description

HANDLING FAILURES IN A WIRELESS COMMUNICATION SYSTEM

[0001] This application is based on and derives the benefit of Indian Provisional Applications 202541017776 filed on 28th February 2025 and 202541034552 filed on 8th April 2025 the contents of which are incorporated herein by reference. The present disclosure is related to the field of wireless networks. More particularly, the present disclosure is related to a method and system for handling secondary cell group (SCG) failure in a wireless communication system.

[0002] Fifth generation (5G) mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “sub 6 gigahertz (GHz)” bands such as 3.5GHz, but also in “above 6GHz” bands referred to as millimeter wave (mmWave) including 28GHz and 39GHz. In addition, implementing sixth generation (6G) mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies is being considered.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced mobile broadband (eMBB), ultra reliable low latency communications (URLLC), and massive machine-type communications (mMTC), there has been ongoing standardization regarding beamforming and massive multi input multi output (MIMO) for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave. In addition, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of bandwidth part (BWP), new channel coding methods such as a low density parity check (LDPC) code for large amounts of data transmission and a polar code for highly reliable transmission of control information, layer two (L2) pre-processing, and network slicing for providing a dedicated network specialized to a specific service are also being used to support services and to satisfy performance requirements.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as vehicle-to-everything (V2X) technologies for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, new radio unlicensed (NR-U) technologies aimed at system operations conforming to various regulation-related requirements in unlicensed bands, new radio (NR) user equipment (UE) power saving technologies, non-terrestrial network (NTN) technologies, which are UE-satellite direct communication technologies for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning technologies.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as industrial Internet of things (IIoT) for supporting new services through interworking and convergence with other industries, integrated access and backhaul (IAB) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and dual active protocol stack (DAPS) handover, and two-step random access for simplifying random access procedures (for example, 2-step random access channel (RACH) for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining network functions virtualization (NFV) and software-defined networking (SDN) technologies, and mobile edge computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices will be connected to communication networks, and it is expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with extended Reality (XR) for efficiently supporting augmented reality (AR), virtual reality (VR), and mixed reality (MR). 5G performance improvement and complexity reduction may be accomplished by utilizing artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing new waveforms for providing coverage in THz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as full dimensional multiple input multiple output (FD-MIMO), array and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of THz band signals, high-dimensional space multiplexing technology using orbital angular momentum (OAM), reconfigurable intelligent surface (RIS) technology, full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] Dual connectivity or more technically multi-radio dual connectivity is specified by 3rd generation Partnership Project (3GPP) in specifications such as TS 37.340. A summary of the details on dual connectivity and measurement gap operations with dual connectivity are given below.

[0009] Next-Generation Radio Access Network (NG-RAN) supports Multi-Radio Dual Connectivity (MR-DC) operation whereby a user equipment (UE) in Radio Resource Control Connected (RRC_CONNECTED) is configured to utilize radio resources provided by two distinct schedulers, located in two different NG-RAN nodes connected via a non-ideal backhaul, one providing NR (New Radio) access and the other one providing either Evolved UMTS Terrestrial Radio Access (E-UTRA) or NR access. One node acts as the Master Node (MN) and the other as the Secondary Node (SN). The MN and SN are connected via a network interface and at least the MN is connected to the core network. NG-RAN supports NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), in which a UE is connected to one Next-Generation Evolved Node B (NG-eNB) (an E-UTRA base station that can connect to 5G core) that acts as a MN and one Generation Node B (gNB) (5G base station) that acts as a SN. The NG-RAN also supports New Radio Evolved Universal Terrestrial Radio Access (NR-E-UTRA) Dual Connectivity and New Radio Dual Connectivity (NE-DC), in which a UE is connected to one gNB that acts as a MN and one NG-eNB that acts as a SN.

[0010] The evolution of mobile communication networks has been marked by continuous efforts to enhance user experience through improved data rates, reduced latency, and increased reliability. The 3rd Generation Partnership Project (3GPP) has played a pivotal role in this evolution, with each release introducing new features and capabilities to address emerging challenges. Handover in NR usually consists of three steps: handover preparation, handover execution and handover completion. gNB may configure the UE to report measurements and based on the reported measurements or based on its own understanding of the network topology, gNB will send RRC Reconfiguration message to handover the UE to another cell called target cell from the source cell. UE accesses the target cell, performs random access and sends RRC Reconfiguration complete message. Release 18 of 3GPP introduced Lower Layers (L1 / L2 layers) Triggered Mobility (LTM) as a solution to the problems associated with latency, signaling overhead, and interruption times inherent in traditional layer 3 mobility procedures. 3gpp also introduced support of RACH-less handover in release 18,where in the UE accesses target cell during a handover without performing random access. RACH-less handover in NR-DC can be RACH-less PSCellChange or RACH-lessPSCellAddition.

[0011] LTM aims to enable a serving cell change via L1 / L2 signaling, thereby significantly reducing latency overhead and interruption time during mobility events. In this procedure, a network node, such as a gNodeB (gNB), configures user equipment (UE) with multiple candidate cells, allowing for the rapid application of pre-configured settings for these candidate cells. The gNB receives L1 measurement reports from the UE and, based on these reports, issues a cell switch command via a Medium Access Control Element (MAC CE). This command directs the UE to switch to a target cell using a previously prepared LTM candidate cell configuration provided through Radio Resource Control (RRC) signaling.

[0012] Thus, it is desired to address the above mentioned disadvantages or other shortcomings or at least provide a useful alternative.

[0013] The principal object of the embodiment disclosed herein is to provide a method and a system for handling SCG failure and RLFs in a wireless communication system.

[0014] Yet another object of the embodiment disclosed herein is to provide a method and a system for self-optimization (including optimizations for minimization of drive tests) of random access in wireless networks like 5G NR and the method and system of optimizing SCG failure in EN-DC.

[0015] Yet another object of the embodiment disclosed herein is to provide a method and a system for optimizing mobility.

[0016] In an aspect, the objectives are achieved by providing a method performed by a user equipment (UE) in a wireless communication system. The method comprises identifying whether the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC); in case that the UE supports the SCG failure information for the EN-DC or the NGEN-DC, setting an information element (IE) in the SCG failure information, wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC; and transmitting, to a network apparatus, the SCG failure information including the IE.

[0017] In an aspect, the objectives are achieved by providing a method performed by a network apparatus in a wireless communication system. The method comprises transmitting, to a user equipment (UE), a radio resource control (RRC) reconfiguration message including information associated with a secondary cell group (SCG) failure; and in case that the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC), receiving, from the UE, an SCG failure information including an information element (IE), wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC, wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format

[0018] In an aspect, the objectives are achieved by providing A user equipment (UE) in a wireless communication system. The UE comprises memory storing instructions; and processing circuitry coupled to the memory and configured, based at least partially on execution of the instructions, to cause the UE to identify whether the UE supports a secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC); in case that the UE supports the SCG failure information for the EN-DC or the NGEN-DC, to set an information element (IE) in the SCG failure information, wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC; and transmit, to a network apparatus, the SCG failure information including the IE.

[0019] In an aspect, the objectives are achieved by providing a network apparatus in a wireless communication system. The network apparatus comprises memory storing instructions; and processing circuitry coupled to the memory and configured, based at least partially on execution of the instructions, to cause the network apparatus to transmit, to a user equipment (UE), a radio resource control (RRC) reconfiguration message including information associated with a secondary cell group (SCG) failure; and in case that the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC), to receive, from the UE, an SCG failure information including an information element (IE), wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC, wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format.

[0020] In an aspect, the objectives are achieved by providing a method for handling SCG failure in a wireless communication system. The method includes detecting whether the UE supports SCG failure in an evolved universal terrestrial radio access (E-UTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation E-UTRA NR(NGEN)-dual connectivity (NGEN-DC). Further, the method includes setting an information element (IE) to indicate random access procedure related information associated with the UE, when the UE supports SCG failure. The random access procedure related information includes information about each random access attempt performed by the UE arranged in a chronological order. Further, the method includes transmitting the IE to a network apparatus.

[0021] In an aspect, the objectives are achieved by providing a UE for handling SCG failure in a wireless communication system. The UE includes a processor, a memory coupled to the processor, and a failure handling controller communicatively coupled to the processor and the memory. The failure handling controller detects whether the UE supports SCG failure in an EN-DC or a NGEN-DC. Further, the failure handling controller sets an IE to indicate random access procedure related information associated with the UE, when the UE supports SCG failure. The random access procedure related information includes information about each random access attempt performed by the UE arranged in a chronological order. Further, the failure handling controller transmits the IE to a network apparatus.

[0022] These and other aspects of the embodiments will be better understood with the following description and accompanying drawings. The descriptions, while indicating preferred embodiments and specific details, are for illustration and not limitation. Many changes and modifications can be made within the scope of the embodiments.

[0023] The present disclosure improves the accuracy and reliability of SCG failure and radio link failure (RLF) handling in dual connectivity environments. It enables more efficient mobility management and optimization of random access procedures in EN-DC and NGEN-DC systems. As a result, overall network performance is enhanced, contributing to improved robustness and support for network self-optimization.

[0024] These and other features, aspects, and advantages of the present embodiments are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0025] Fig. 1 is a schematic diagram that illustrates a schematic of a UE implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein.

[0026] Fig. 2 is a flow chart that illustrates a proposed method for SCG failure handling in EN-DC / NGEN-DC according to an embodiment as disclosed herein.

[0027] Fig. 3 is a flow chart that illustrates a proposed method for SHR for RACH-less handover according to an embodiment as disclosed herein.

[0028] Fig. 4 is a flow chart that illustrates a proposed method for SPR for RACH-less handover according to an embodiment as disclosed herein.

[0029] Fig. 5 is a flow diagram that illustrates a method for handling SCG failure in a wireless communication system according to an embodiment as disclosed herein.

[0030] Fig. 6 is a flow diagram that illustrates a method for handling SCG failure due to a reconfiguration with sync according to an embodiment as disclosed herein.

[0031] Fig. 7 is a flow diagram that illustrates a method for handling RLF reports in a wireless communication system according to an embodiment as disclosed herein.

[0032] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with a plurality of other embodiments to form new embodiments. The term “or” as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples are not be construed as limiting the scope of the embodiments herein.

[0033] As is existing in the field, embodiments are described and illustrated in terms of blocks that carry out a described function or functions. These blocks, which referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, and the like, and optionally be driven by firmware and software. The circuits, for example, be embodied in a plurality of semiconductor chips, or on substrate supports such as printed circuit boards, and the like. The circuits constituting a block be implemented by dedicated hardware, or by a processor (e.g., a plurality of programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments be physically separated into two or more interacting and discrete blocks without departing from the scope of the proposed method. Likewise, the blocks of the embodiments be physically combined into more complex blocks without departing from the scope of the proposed method.

[0034] The drawings help explain the technical features, but the embodiments are not limited to them. The proposed method includes any modifications, equivalents, and substitutes beyond those shown. Terms like first, second, etc., are used to distinguish elements and do not limit them.

[0035] The following SCG and Master Cell Group (MCG) failure cases may occur in NR (based on TS 37.340).

[0036] - Secondary Cell Group Radio Link Failure (SCG RLF);

[0037] - SCG beam failure while the SCG is deactivated;

[0038] - SN addition / change failure;

[0039] - For EN-DC, NGEN-DC and NR-DC, SCG configuration failure or CPC configuration failure (only for messages on SRB3);

[0040] - For EN-DC, NGEN-DC and NR-DC, SCG RRC integrity check failure (on SRB3);

[0041] - For EN-DC, NGEN-DC and NR-DC, consistent UL LBT failure on PS Cell;

[0042] - For IAB-MT, reception of a BH RLF indication from SCG;

[0043] - CPA / CPC execution failure.

[0044] The UE sends SCG failure information NR (LTE RRC message SCGFailureInformationNR) to report SCG failures in EN-DC to MN. The purpose of this procedure is to inform MN about an SCG failure the UE has experienced i.e. SCG radio link failure, failure of SCG reconfiguration with sync, SCG configuration failure for RRC message on SRB3, SCG integrity check failure, consistent uplink LBT failures on PS Cell for operation with shared spectrum channel access etc.

[0045] The existing mechanisms fail to provide methods for reporting of information in SCG failure information for EN-DC and NGEN-DC for Self-Organizing Networks (SON).

[0046] Despite the advancements introduced by RACH-less handover and LTM, several challenges remain unaddressed. One significant issue is the logging of successful handover reports (SHR) during RACH-less handovers. The current mechanisms do not provide methods for accurately logging these events, which are crucial for network performance analysis and optimization. Similarly, there is a lack of methods for logging Successful Primary Secondary Cell (PS Cell) Reports (SPR) during RACH-less handovers, which are necessary for ensuring the reliability and effectiveness of the mobility process.

[0047] Further, handling LTM failures is another critical area that requires attention. The existing procedures do not adequately address the steps to be taken when an LTM cell switch fails, potentially leading to service interruptions and degraded user experience. The ability to manage and recover from such failures is essential for maintaining the robustness and reliability of the network.

[0048] The 3GPP specifications, including versions 18.5.1 of TS 38.331, 38.321, 38.306, 37.340, 38.300, provide a comprehensive framework for LTM and RACH-less handover and serve as background for this invention. For instance, according to TS 38.331, a UE facing radio link failure or handover failure logs failedPCellId in RLF report to indicate the cell where the failure occurs. However, they do not encompass the methods needed to address the aforementioned challenges related to SHR logging, SPR logging, and LTM failure handling. These gaps highlight the need for further innovations to enhance the effectiveness and reliability of mobility procedures.

[0049] In summary, while LTM and RACH-less handover represent a significant advancement in reducing latency and signaling overhead during mobility events, there are critical areas that require further development. Addressing the issues of logging successful handover and PS Cell reports, as well as managing LTM failures, is essential for optimizing network performance and ensuring a seamless user experience.

[0050] In an embodiment, for EN-DC or NGEN-DC, the UE includes the SCG random access information related to the performed random access procedure related information. An Information Element (IE) such as PerRA-InfoNR contains the information about the performed random access. If the SCG failure is due to the reconfiguration with Sync failure, the UE includes the random access information related to the reconfiguration with Sync in SCGFailureInformationNR. The information could be the RA report or per-RA info list related to the reconfiguration with Sync. If the SCG failure is due to the random access problem when timer such as T304 is running, the UE includes the random access information related to the failed random access procedure in SCGFailureInformationNR. The information could be the RA report or per-RA info list related to the random access procedure of which failure lead to the SCGFailureInformationNR transmission.

[0051] In an embodiment, the UE sets timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG

[0052] In an embodiment, the UE sets timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG or randomAccessProblem when the SCG failure was declared while T304 was running, if the last RRCReconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PSCellChange).

[0053] In an embodiment, the UE sets timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG or randomAccessProblem when the SCG failure was declared while T304 was running, if the last RRCReconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared , for PSCellAddition.

[0054] In an embodiment, the UE sets previousPSCellId to the physical cell identity and carrier frequency of the source PS Cell associated to the last received RRCReconfiguration message including reconfigurationWithSync when the failure type is other than synchReconfigFailureSCG or randomAccessProblem when the SCG failure was declared while T304 was running if the last RRCReconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PSCellChange).

[0055] An example specification including SCG failure information NR according to TS 36.331 is given below:

[0056] The SCGFailureInformationNR message is used to provide information regarding NR SCG failures detected by the UE.

[0057] -- ASN1STARTSCGFailureInformationNR-r15 ::= SEQUENCE {criticalExtensions CHOICE {c1 CHOICE {scgFailureInformationNR-r15 SCGFailureInformationNR-r15-IEs,spare3 NULL, spare2 NULL, spare1 NULL},criticalExtensionsFuture SEQUENCE {}}}SCGFailureInformationNR-r15-IEs ::= SEQUENCE {failureReportSCG-NR-r15 FailureReportSCG-NR-r15 OPTIONAL,nonCriticalExtension SCGFailureInformationNR-v1590-IEs OPTIONAL}SCGFailureInformationNR-v1590-IEs ::= SEQUENCE {lateNonCriticalExtension OCTET STRING OPTIONAL,nonCriticalExtension SEQUENCE {} OPTIONAL}FailureReportSCG-NR-r15 ::= SEQUENCE {failureType-r15 ENUMERATED {t310-Expiry, randomAccessProblem,rlc-MaxNumRetx,synchReconfigFailureSCG, scg-reconfigFailure,srb3-IntegrityFailure, dummy},measResultFreqListNR-r15 MeasResultFreqListFailNR-r15 OPTIONAL,measResultSCG-r15 OCTET STRING OPTIONAL,...,[[ locationInfo-r16 LocationInfo-r10 OPTIONAL,logMeasResultListBT-r16 LogMeasResultListBT-r15 OPTIONAL,logMeasResultListWLAN-r16 LogMeasResultListWLAN-r15 OPTIONAL,failureType-v1610 ENUMERATED {t312-Expiry, scg-lbtFailure,beamFailureRecoveryFailure, bh-RLF-r16,beamFailure-r17,spare3, spare2, spare1} OPTIONAL]]]],[[previousPSCellId-r19 SEQUENCE {physCellId-r19 PhysCellIdNR-r15,carrierFreq-r19 ARFCN-ValueNR-r15} OPTIONAL,failedPSCellId-r19 SEQUENCE {physCellId-r19 PhysCellIdNR-r15,carrierFreq-r19 ARFCN-ValueNR-r15} OPTIONAL,timeSCGFailure-r19 INTEGER (0..1023) OPTIONAL,rach-ReportListNR-r19 OCTET STRING]]}MeasResultFreqListFailNR-r15 ::= SEQUENCE (SIZE (1..maxFreqNR-r15)) OF MeasResultFreqFailNR-r15MeasResultFreqFailNR-r15 ::= SEQUENCE {carrierFreq-r15 ARFCN-ValueNR-r15,measResultCellList-r15 MeasResultCellListNR-r15 OPTIONAL,...}

[0058] The following are the field descriptions of the SCGFailureInformationNR.

[0059] failedPSCellId field indicates the physical cell id and carrier frequency of the cell in which SCG failure is detected or the target PS Cell of the failed PS Cell change or failed PS Cell addition.

[0060] failure Type field indicates the cause of the SCG failure. When the field failureType-v1610 is included, the network ignores the field failureType-r15.

[0061] measResultFreqListNR field contains available results of measurements on NR frequencies the UE is configured to measure by measConfig.

[0062] measResultSCG includes the NR MeasResultSCG-Failure IE as specified in TS 38.331

[0082] . The field contains available results of measurements on NR frequencies the UE is configured to measure by the NR RRCConfiguration message.

[0063] previousPSCellId field indicates the physical cell id and carrier frequency of the cell that is the source PS Cell of the last PS Cell change. In case of PS Cell addition failure, this field is absent.

[0064] rach-ReportListNR field is used to indicate the list of NR RACH report information, including the NR RA-ReportList IE, which is specified in TS 38.331

[0082] .

[0065] timeSCGFailure field is used to indicate the time elapsed since the last execution of RRCReconfiguration with reconfigurationWithSync for the SCG until the SCG failure. Actual value = field value * 100ms. The maximum value 1023 means 102.3s or longer.

[0066] A 5G NR radio access network also known as NG-RAN (Next Generation Radio Network) comprises of a number of NR base stations knows as gNBs. gNBs can be connected to each other through Xn interface, and will be connected to various core network elements like AMF (Access and Mobility Management Function), UPF (User Plane Function) etc. Further gNBs can be divided into two physical entities named CU (Centralized Unit) and DU (Distributed Unit). CU provides support for the higher layers of the protocol stack such as SDAP (Session Data Application Protocol), PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) while DU provides support for the lower layers of the protocol stack such as RLC (Radio Link Control), MAC (Medium Access Control) and Physical layer. Each gNB can have multiple cells serving many UEs (User Equipment). There are a large number of algorithms and configuration parameters used in NG-RAN. Especially, it is a very difficult task to identify the most optimal radio parameters and operators used to resort to manual techniques like drive tests to identify the parameters. However, such manual parameter tuning is a costly operation since it depends on a lot of factors like the number of users, number of neighbors, maximum throughput in the cell, average throughput in the cell etc. Further, whenever a neighbor gNB is installed or a new service is introduced, many of these manual operations need to be repeated. To resolve this problem, 3gpp has introduced SON techniques in the wireless technologies like NR. SON was first introduced in 3gpp release 9, in LTE. SON solutions can be divided into three categories: Self-Configuration, Self-Optimization and Self-Healing. The SON architecture can be a centralized, distributed or a hybrid solution.

[0067] For the optimization of RACH in SN (NR cell), UE sends SN RA Report for EN-DC and (NG) EN-DC to the MN and MN forwards the RA report to the SN.

[0068] The 3gpp V18.4.0 version of TS 36.331, TS 36.306, TS 38.331, TS 38.321, TS 38.300 and TS 38.304 are considered as relevant background for this invention.

[0069] In an embodiment, the invention proposes methods for reporting of information in SCGFailureInformationNR for EN-DC and NGEN-DC for SON.

[0070] In an embodiment, the UE includes random access information (RA-report or per-RA information) in RRC message send for reporting SCG failure information if the failure type of SCG (according to TS 38.331 or TS 36.331) is synchReconfigFailureSCG (failure for performing reconfiguration with sync , i.e. failure for performing PSCell Change or PSCell Addition). If the ReconfigurationwithSync for PS Cell addition or PSCellChange is not successful, UE includes the random access information in the RRC message. In an embodiment, this may be applied in EN-DC or NGEN-DC. In an extended embodiment, this may be applied in NR-DC.

[0071] In an embodiment, if the UE sends SCGFailureInformationNR in EN-DC or NGEN-DC and the failure type of SCG is set to synchReconfigFailureSCG, UE includes the random access information in the SCGFailureInformationNR. If the UE sends SCGFailureInformationNR in EN-DC or NGEN-DC and the failure type of SCG is set to any other failure cause, UE avoids including the random access information in the SCGFailureInformationNR. In a specific embodiment, if the failure type of SCG is set to randomAccessProblem, UE avoids including the random access information in the SCGFailureInformationNR. Such an approach helps to keep the random access information to the most essential cause.

[0072] In an embodiment, for NR -DC, if the failure type of SCG is set to random Access Problem, UE avoids including the random access information in the SCG failure information.

[0073] In an embodiment, for EN-DC or NGEN-DC, UE includes the SCG random access information in SCG failure information NR as a SEQUENCE of OCTET STRINGS encoded according to SCG RAT (NR) ASN.1. Each OCTET STRING comprise of one or more of perRAInfoList, perRAInfoList-v1660, perRAInfoList-v1840 and the like, encoded according to SCG RAT (NR) ASN.1.

[0074] In an embodiment, the UE includes the per-RA information in SCG failure information NR according to the below structure:

[0075] SCGFailureInformationNR-r15 ::= SEQUENCE {PerRA-InfoNR-R19 PerRA-InfoNR-R19 OPTIONAL,}PerRA-InfoNR-R19 SEQUENCE {perRAInfoListNR OCTETSTRING CONTAINING PerRAInfoList-r16 OPTIONAL,perRAInfoList-v1660-NR OCTETSTRING CONTAINING PerRAInfoList-v1660 OPTIONAL,perRAInfoList-v1840-NR OCTETSTRING CONTAINING PerRAInfoList-v1840 OPTIONAL,...}PerRA-InfoNR-R19 includes the random access information according to E-UTRA ASN.1 which contains perRAInfoListNR, perRAInfoList-v1660-NR, perRAInfoList-v1840-NR encoded according to NR ASN.1 according to the IE types defined in TS 38.331.

[0076] In an embodiment, an LTE base station which receives PerRA-InfoNR-R19, retrieves the perRAInfoListNR, perRAInfoList-v1660-NR, perRAInfoList-v1840-NR and forwards to a 5G base station (gNB).

[0077] Technical advantages of the embodiment: Reporting various NR information within E-UTRA container allows the UE to report only the information relevant to the performed random access. If a single OCTETSTRING is send, UE will either need to send dummy values for the random access information it has or will be able to send only limited information, which will reduce the efficiency of random access optimisation, for e.g, the beam related information wouldn’t be send in such a case.

[0078] In an embodiment, when a UE receives SHR configuration, the UE performs handover (such as upon receiving RRCReconfiguration including reconfigurationWithSync in NR) and receives SHR configuration. Further, the UE performs SHR determination upon indication from lower layers that the RACH-less handover has been successfully completed for the MCG. This allows the UE to report SHR for the following cases- 1. Near failure due to radio link failure timer (T310 / T312) expiry 2. Near failure due to the delay in successfully completing the rachless handover in the target cell.

[0079] In an embodiment, when the UE receives SPR configuration, the UE performs PS Cell addition or PS Cell Change (such as upon receiving RRCReconfiguration including reconfigurationWithSync for NR SCG) and receives SPR configuration. Furthermore, the UE performs SPR determination upon indication from lower layers that the RACH-less handover has been successfully completed for the MCG. This allows the UE to report SPR for the following cases- 1. Near failure due to radio link failure timer (T310 / T312) expiry 2. Near failure due to the delay in successfully completing the rachless PSCell addition or rachless PSCellChange in the target cell.

[0080] The SHR (Successful Handover Report) provides the network with awareness of information when a handover is successful. This may, for instance, give the network potential information even when a handover is successful, as a successful handover does not necessarily mean it is entirely unproblematic. The handover may take a long time to complete. The network configures the UE (User Equipment) with certain conditions, and if those conditions are fulfilled, the UE will log the successful handover report.

[0081] The successful handover report can contain various types of information, such as source and target cell information, measurements of neighboring cells, UE location information, and the time since CHO (Conditional Handover) reconfiguration. Additionally, the SHR includes the cause, T304, T310, and T312 timers, which inform the network of the reason why the SHR was triggered. The triggering may be based on the timer having elapsed more than a certain percentage. Other details in the SHR include random access information, user plane interruption time during the handover, C-RNTI (Cell Radio Network Temporary Identifier), E-UTRA (Evolved Universal Terrestrial Radio Access) information such as target cell ID and E-UTRA C-RNTI, and the time since SHR.

[0082] The conditions for logging SHR include:

[0083] a. T310 threshold (thresholdPercentageT310 in NR): This field indicates the threshold for the ratio in percentage between the elapsed T310 timer and the configured value of the T310 timer. Detailed behavior can be found in 3GPP specifications such as TS 38.331.

[0084] b. The T312 threshold (thresholdPercentageT312 in NR) indicates the threshold for the ratio in percentage between the elapsed T312 timer and the configured value of the T312 timer. Detailed behavior can be found in 3GPP specifications such as TS 38.331.

[0085] c. The T304 threshold (thresholdPercentageT304 in NR) indicates the threshold for the ratio, in percentage, between the elapsed T304 timer and the configured value of the T304 timer. Detailed behavior can be found in 3GPP specifications such as TS 38.331.

[0086] The SHR gives the network awareness of information when a handover is successful. This may, for instance, give the network potential information even when a handover is successful, as a successful handover does not mean that it is entirely unproblematic, as the handover may take a long time to complete.

[0087] To detect a sub-optimal successful PS Cell change or sub-optimal successful PS Cell addition event, the UE may report information related to successful PS Cell Addition and Successful PS Cell Change. This information could be configured to be stored and reported in a report called Successful PS Cell Report (SPR). An example specification is given below.

[0088] SuccessPSCell-Report-r18 ::= SEQUENCE {pCellId-r18 CGI-Info-Logging-r16,sourcePSCellInfo-r18 SEQUENCE {sourcePSCellId-r18 CGI-Info-Logging-r16,sourcePSCellMeas-r18 MeasResultSuccessHONR-r17 OPTIONAL} OPTIONAL,targetPSCellInfo-r18 SEQUENCE {targetPSCellId-r18 CHOICE {cellGlobalId-r18 CGI-Info-Logging-r16,pci-arfcn-r18 PCI-ARFCN-NR-r16},targetPSCellMeas-r18 MeasResultSuccessHONR-r17 OPTIONAL},measResultNeighCells-r18 SEQUENCE {measResultListNR-r18 MeasResultList2NR-r16 OPTIONAL,measResultListEUTRA-r18 MeasResultList2EUTRA-r16 OPTIONAL} OPTIONAL,spr-Cause-r18 SPR-Cause-r18 OPTIONAL,timeSinceCPAC-Reconfig-r18 TimeSinceCPAC-Reconfig-r18 OPTIONAL,locationInfo-r18 LocationInfo-r16 OPTIONAL,ra-InformationCommon-r18 RA-InformationCommon-r16 OPTIONAL,sn-InitiatedPSCellChange-r18 ENUMERATED {true} OPTIONAL,...}

[0089] Radio Link Failure procedures are introduced to allow a UE to regain its radio link in case the radio link fails. After having been triggered, the UE performs RRC re-establishment, which means that the UE performs cell selection to potentially find a new cell (the same cell is a possible outcome) and connects to the cell. The Radio Link Failure can be declared in a number of cases. Some examples are:

[0090] UE out of sync: The UE measures the cell strength through Radio Link Monitoring. If the cell strength is below a certain threshold for a configurable amount of times (N310), the UE triggers a timer (T310) for the UE to recover. If it does not recover, the UE declares an RLF. The recover condition is that the UE receives an in-sync indication a configurable amount of times (N311) during the T310 timer duration.

[0091] RLC PDUs are re-transmitted a number of times: The network configures a number of times (maxRetxThreshold) that an RLC PDU may be attempted to be re-transmitted.

[0092] Random access problems: This can occur when the UE is in connected mode and the UE is trying to re-synchronize, for instance after losing uplink synchronization.

[0093] Backhaul (BH) RLF (IAB related): Failure of backhaul links

[0094] Uplink Listen Before Talk (LBT) failure: This is when the UE fails LBT when on unlicensed band.

[0095] Although a handover failure does cause the UE to declare a Radio Link Failure, a handover failure is still treated as a radio link failure in some cases, thus handover failures are considered a part of the RLF report.

[0096] The RLF report may consist of the following information: measurements of serving and neighboring cells, the C-RNTI the UE used, the previous Cell ID, the failed Cell ID, the Reconnect cell ID, time until reconnection, reestablishment cell ID, time of connection failure, time since the failure, connection failure type (RLF or a Handover Failure), RLF cause (t310 expiry, receiving lower layer out-of-sync indications, random access problem, RLC maximum number of retransmissions, beam failure recovery, LBT, IAB backhaul radio link failure, T312 expiry), location info of the UE, no suitable cell found, random access information, handover type (Conditional Handover (CHO) or Dual Active Protocol Stack (DAPS)), time since CHO reconfiguration or DAPS failure, E-UTRA RLF report including E-UTRA measurement result and cell ID of E-UTRA cell, CHO information such as CHO cell ID and CHO candidate cell list, MCG failure causes (T316 expiry or SCG deactivation), SCG failure causes (same as RLF cause), time elapsed since SCG failure, voice fallback handover, RSSI serving and neighbor cell measurement results, BWP info, fields such as ltm-RecoveryCellId which is used to indicate the candidate target cell for LTM cell switch included in ltm-Config associated with the MCG that the UE selected for LTM based recovery while T311 was running and the failedPCellId may be logged to indicate the cell where the RLF or handover failure or LTM cell switch failure or conditional LTM cell switch failure.

[0097] When the RLF is for SCG, UE may include the information for SON / MDT in SCGFailureInformation. If available, log the L1 measurements for the serving cell, target cell, and other LTM candidate cells in the RLF report upon RLF or mobility failure.

[0098] Conditional LTM: A UE may be configured with a condition, and upon the fulfillment of the condition, UE executes LTM cell switch. The condition may be based on L3 measurement events or L1 measurement events as described in 3GPP documents.

[0099] For example, UE may be configured to perform conditional LTM when the serving cell’s measured L1 / L3 RSRP or RSRQ is below a threshold and that of the neighbor cell is above a threshold. In another case, UE may be configured to perform conditional LTM when the neighbor cell’s measured L1 / L3 RSRP or RSRQ is better than an offset of that of the serving cell.

[0100] In an embodiment, the issues addressed in this invention are methods of logging SHR during RACH-less LTM cell switch, methods of logging SPR during RACH-less LTM cell switch, and methods of handling LTM failure.

[0101] Referring now to the drawings, and more particularly to FIGS. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0102] Fig. 1 is a schematic diagram that illustrates a schematic of a UE (100) implemented to carry out the disclosed subject matter according to an embodiment as disclosed herein. Examples of the UE (100) can include, but are not limited to, consumer electronics (such as mobile phones and smartphones), tablets, wearable devices, computing devices (such as laptops, notebooks, desktops, workstations, etc.), IoT devices, automotive systems (such as connected cars, autonomous vehicles, Vehicle-to-Everything (V2X) communication devices, etc.), enterprise devices (such as robotics), specialized equipment (such as medical devices, public safety devices, etc.), and media devices (such as gaming consoles, streaming devices, etc.).

[0103] In an embodiment as depicted in Fig. 1, the UE (100) includes a processor (102), a memory (104), an I / O interface (106), and a failure handling controller (108) coupled to the processor (102) and the memory (104). Each component is explained in further detail below.

[0104] The processor (102) communicates with the memory (104), the I / O interface (106), and the failure handling controller (108). The processor (102) is configured to execute instructions stored in the memory (104) and to perform one or more operations described herein. The processor (102) includes one or more processors and can be a general-purpose processor such as a CPU, an application processor (AP), or the like, a graphics processing unit (GPU), a visual processing unit (VPU), and / or an AI-dedicated processor such as a neural processing unit (NPU). The processor (102) may support parallel processing and / or hardware acceleration for executing computational tasks.

[0105] The memory (104) includes storage for setting the IE to indicate random access procedure. It comprises volatile and / or non-volatile memory including one or more computer-readable storage media such as magnetic hard disks, optical disks, floppy disks, flash memories, EPROM, and EEPROM. The memory (104) may include error detection and / or error correction (e.g., ECC) to improve data integrity.

[0106] Information is transmitted between the memory (104) and external peripheral devices via the I / O interface (106), which connects input-output devices associated with the UE (100). The failure handling controller (108) also communicates with the I / O interface (106) and the memory (104). This coupling allows data transfer and communication between components, enabling the failure handling controller (108) to handle SCG failure in a wireless communication system.

[0107] The failure handling controller (108) is a novel hardware controller implemented as an integrated circuit within the UE (100) and is configured to handle SCG failure. In an embodiment, the failure handling controller (108) includes dedicated hardware circuitry comprising a register / bus interface coupled to the processor (102), a timing / control circuit, an analog front end including a low-noise amplifier and an analog-to-digital converter to acquire and digitize input signals, and digital processing circuitry (e.g., MCU / DSP logic) to handle SCG failure, and synthesize the real-time user response, with intermediate data stored in local buffers and / or the memory (104).

[0108] In an embodiment, the failure handling controller (108) detects whether the UE supports SCG failure in an EN-DC or a NGEN-DC. Further, the failure handling controller (108) sets an IE indicate random access procedure related information associated with the UE (100), when the UE (100) supports SCG failure. The random access procedure related information includes information about each random access attempt performed by the UE (100) arranged in a chronological order. The IE is a 'perRA-InfoListNR', which is a sequence of octet strings in a NR format. The octet strings includes information of a type that includes a type PerRAInfoList-r16, a PerRAInfoList-v1660, a PerRAInfoList-v1840, and the like. Further, the failure handling controller (108) transmits the IE to a network apparatus.

[0109] The network apparatus includes various hardware and software components that facilitate communication between user equipment and network infrastructure. Examples of the network apparatus can include, but is not limited to Base Stations (such as macro cells, small cells, femtocells, picocells) for wireless communication, Antennas and RF Units (e.g., MIMO, beamforming) to enhance signal coverage and data throughput, Core Network Equipment (e.g., MMEs, S-GWs, P-GWs in 4G; AMFs, UPFs in 5G) for data routing, mobility, and session control, Network Function Virtualization (NFV) and Software-Defined Networking (SDN) for dynamic resource allocation and scalability, Edge Computing Nodes (e.g., MEC servers) for low-latency processing, Backhaul and Transport Equipment (e.g., fiber-optic links, microwave relays, Ethernet switches) to connect base stations to the core network, Network Management Systems (NMS) and Operation Support Systems (OSS) for network configuration, fault management, and optimization, Radio Network Controllers (RNCs) in 3G, Distributed Units (DUs), and Centralized Units (CUs) in 5G, Network Slicing Components for virtualized resource allocation, Security elements (e.g., Firewalls, IDS, AAA Servers) for secure communication.

[0110] Fig. 2 is a flow chart that illustrates a proposed method for SCG failure handling in EN-DC / NGEN-DC according to an embodiment as disclosed herein. The flow chart includes steps (202-210). At step (202), the UE (100) detects SCG failure in EN-DC or NGEN-DC. At step (204), the UE (100) includes perRAInfoListNR, perRAInfoList-v1660-NR, perRAInfoList-v1840-NR in NR ASN.1 format to indicate the performed random access procedure related information. This is included when the failure type is set to synchReconfigFailureSCG or randomAccessProblem and the SCG failure was declared while T304 was running in SCGFailureInformationNR. At step (206), the UE (100) sets the timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message by including the reconfigurationWithSync until declaring the SCG failure if the last execution of RRCReconfiguration message including the reconfigurationWithSync was for PSCellChange in SCGFailureInformationNR.

[0111] At step (208), the UE (100) sets the previousPSCellId to the physical cell identity and carrier frequency of the source PS Cell associated to the last received RRCReconfiguration message. The UE (100) includes reconfigurationWithSync for the SCG, if available in SCGFailureInformationNR. At step (210), the UE (100) transmits the SCGFailureInformationNR message.

[0112] In an embodiment, the UE (100) which has experienced SCG failure in EN-DC or NGEN-DC includes an information element (such as PerRA-InfoNR) to provides detailed information about each of the random access attempts in the chronological order of the random access attempts. The information element is a SEQUENCE of OCTET STRINGS in NR format. OCTET STRINGS could contain information of type PerRAInfoList-r16, PerRAInfoList-v1660, PerRAInfoList-v1840 etc. If an OCTET STRING containing information of type PerRAInfoList-v1660 is included along with an OCTET STRING containing information of type PerRAInfoList-r16, the information in the OCTET STRING contain information of type PerRAInfoList-r1660 has the same number of entries in the same order as the information in the OCTETSTING containing information of type PerRAInfoList. i.e., if both perRAInfoList-v1660-NR and perRAInfoListNR are included, (OCTET STRING for) perRAInfoList-v1660-NR contains same number of entries in the same order as the information in the (OCTET STRING for) perRAInfoListNR.

[0113] In an embodiment, for EN-DC or NGEN-DC, the UE (100) includes the SCG random access information related to the performed random access procedure related information. PerRA-InfoNR contains the information about the performed random access. PerRA-InfoNR contains NR random access information and is send using E-UTRA ASN.1. Sending NR information as a SEQUENCE of OCTET STRING in side a E-UTRA container allows sending the information which is available with the UE, i.e. one, two or three of PerRAInfoList-r16, PerRAInfoList-v1660, PerRAInfoList-v1840 in the SCGFailureInformationNR message. This also allows the network to get required information for failures such as beam failure information which leads to random access.

[0114] In an embodiment, if the SCG failure is due to the reconfiguration with Sync failure, the UE (100) includes the random access information related to the reconfiguration with Sync in SCG failure information NR. The information could be the RA report or per-RA info list related to the reconfiguration with Sync. If the SCGFailure occurred due to PS Cell Change failure, the UE (100) includes the random access information related to the random access attempts performed during PS Cell Change. If the SCGFailure occurred due to PS Cell addition failure, the UE (100) includes the random access information related to the random access attempts performed during PS Cell addition. i.e. the Random access information will be for the random accesses performed in the target cell for PS Cell change or addition.

[0115] In an embodiment, if the SCG failure is due to the random access problem, the UE (100) includes the random access information related to the failed random access procedure in SCG failure information NR. The information could be the RA report or per-RA info list related to the random access procedure of which failure lead to the SCG failure information NR transmission. If the SCGFailure occurred due to PS Cell Change failure, the UE (100) includes the random access information related to the random access attempts performed during PS Cell Change. If the SCGFailure occurred due to PS Cell addition failure, the UE (100) includes the random access information related to the random access attempts performed during PS Cell addition. i.e. the Random access information will be for the random accesses performed in the target cell for PS Cell change or addition.

[0116] In an embodiment, the UE (100) sets timeSCGFailure to the elapsed time since the last execution of RRC reconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG.

[0117] In an embodiment, the UE (100) sets timeSCGFailure to the elapsed time since the last execution of RRC reconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG or random access problem when the SCG failure was declared while T304 was running, if the last RRC reconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PS Cell Change).

[0118] In an embodiment, the UE (100) sets timeSCGFailure to the elapsed time since the last execution of RRC reconfiguration message including the reconfigurationWithSync (for the SCG) until declaring the SCG failure when the failure type is other than synchReconfigFailureSCG or random access problem when the SCG failure was declared while T304 was running, if the last RRC reconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS cell in which the SCG failure was declared , for PS Cell Addition.

[0119] In an embodiment, the UE (100) sets previousPSCellId to the physical cell identity and carrier frequency of the source PS Cell associated to the last received RRC reconfiguration message including reconfigurationWithSync when the failure type is other than synchReconfigFailureSCG or random access problem when the SCG failure was declared while T304 was running if the last RRC reconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PS Cell Change).

[0120] The embodiments for the case where the UE (100) includes additional information in SCGFailureInformationNR can be generalized to the case where the UE (100) includes information for optimization in the message send for reporting Inter-RAT SCG failure. For example, it may be applicable for the UE (100) sending SCG failure information to a 5G master node when the 6G SCG faces SCG failure. The content can be included in SCGFailureInformation6G message.

[0121] In an embodiment, according to TS 36.331, the following are the actions related to transmission of SCGFailureInformationNR message.

[0122] 1> [if the UE (100) supports SCG failure for mobility robustness optimization]:2> if the failure Type is set to synchReconfigFailureSCG; orif the failure Type is set to randomAccessProblem and the SCG failure was declared while T304 was running3> set perRAInfoListNR to indicate the performed random access procedure related information as specified in 5.7.10.5 of TS 38.331.3> set the failedPSCellId to the physical cell identity and carrier frequency of the target PS Cell of the failed PS Cell change or failed PS Cell addition;3> set the previousPSCellId to the physical cell identity and carrier frequency of the source PS Cell associated to the last received RRCReconfiguration message including reconfigurationWithSync of the PSCellChangd, if available;3> set the timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message including the reconfigurationWithSync until declaring the SCG failure;2> else:3> set the failedPSCellId to the physical cell identity and carrier frequency of the PS Cell in which the SCG failure was declared;3> set the timeSCGFailure to the elapsed time since the last execution of RRCReconfiguration message including the reconfigurationWithSync until declaring the SCG failure;3> set the previousPSCellId to the physical cell identity and carrier frequency of the source PS Cell associated to the last received RRCReconfiguration message including reconfigurationWithSync, if available;

[0123] In an embodiment, according to TS 36.331, the following are the actions related to transmission of SCGFailureInformationNR message.

[0124] 1> [if the UE (100) supports SCG failure for mobility robustness optimization]:2> if thefailure Typeis set tosynchReconfigFailureSCG; orif thefailure Typeis set torandomAccessProblemand the SCG failure was declared while T304 was running3> setperRAInfoListNRto indicate the performed random access procedure related information as specified in 5.7.10.5 of TS 38.331.3> set thefailedPSCellIdto the physical cell identity and carrier frequency of the target PS Cell of the failed PS Cell change or failed PS Cell addition;3> set thepreviousPSCellIdto the physical cell identity and carrier frequency of the source PS Cell associated to the last receivedRRCReconfigurationmessage includingreconfigurationWithSyncof the PSCellChangd, if available;3> set thetimeSCGFailureto the elapsed time since the last execution ofRRCReconfigurationmessage including thereconfigurationWithSyncuntil declaring the SCG failure;2> else:3> set thefailedPSCellIdto the physical cell identity and carrier frequency of the PS Cell in which the SCG failure was declared;3> if the lastRRCReconfigurationmessage including thereconfigurationWithSyncfor the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PSCellChange):4> set thetimeSCGFailureto the elapsed time since the last execution ofRRCReconfigurationmessage including thereconfigurationWithSyncuntil declaring the SCG failure;4> set thepreviousPSCellIdto the physical cell identity and carrier frequency of the source PS Cell associated to the last receivedRRCReconfigurationmessage includingreconfigurationWithSync, if available;

[0125] In an embodiment, the UE (100) includes the previousPSCellId if the last RRCReconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PS Cell in which the SCG failure was declared from another PS Cell (i.e. for PSCellChange). In the prior arts, the UE (100) logs the previousPSCellId if there was no PSCell Addition failure, however according to this embodiment, if the UE (100) entered a SCG cell through PSCell addition and the PSCell addition failed, the UE (100) does not include the previousPSCellId in the SCGFailureInformation or SCGFailureInformationNR messages.

[0126] Fig. 3 is a flow chart that illustrates a proposed method for SHR for RACH-less handover according to an embodiment as disclosed herein. The method includes steps (302-304). In an embodiment, at step (302), the method includes the UE (100) receiving SHR configuration and performing handover (such as upon receiving RRCReconfiguration including reconfigurationWithSync in NR) and receiving SHR configuration. At step (304), the method includes the UE (100) performing SHR determination upon indication from lower layers that the RACH-less handover has been successfully completed for the MCG (or the primary cell in single connectivity).

[0127] In an embodiment, the UE (100) may determine SHR for RACH-less handover upon receiving an indication from lower layers that RACH-less handover has been successfully completed for the MCG.

[0128] In an embodiment, the UE (100) may determine SHR for RACH-less handover upon receiving the downlink assignment on the PDCCH for the MAC entity's C-RNTI after the first PUSCH transmission to the Serving Cell of the MCG.

[0129] In an embodiment, the UE (100) may determine SHR for RACH-less handover upon receiving the uplink grant on the PDCCH for the MAC entity's C-RNTI after the first PUSCH transmission to the Serving Cell of the MCG.

[0130] In an embodiment, the UE (100) may determine SHR for RACH-less handover upon receiving the uplink grant for a new transmission on the same HARQ process used for the first PUSCH transmission to the Serving Cell of the MCG.

[0131] In an embodiment, the UE (100) performs following steps.

[0132] 1. The UE (100) may receive SHR configuration from the source PCell.

[0133] 2. The UE (100) performs handover (such as upon receiving RRCReconfiguration including reconfigurationWithSync in NR) including configuration for RACH-less handover and may receive SHR configuration configured by target PCell or source PCell.

[0134] 3. The UE (100) attempts to perform rach-less handover, and if the UE RRC receives indication from lower layers that the RACH-less handover has been successfully completed for the MCG, the UE (100) performs SHR determination.

[0135] In an embodiment, according to TS 38.331, the UE (100) shall perform the following actions upon reception of the RRCReconfiguration, upon execution of the conditional reconfiguration (CHO, CPA, CPC, or subsequent CPAC), or upon execution of an LTM cell switch:

[0136] 1> set the content of theRRCReconfigurationCompletemessage as follows:2> if theRRCReconfigurationincludes thereconfigurationWithSyncinspCellConfigof an MCG:3> if the UE (100) was configured withsuccessHO-Configwhen connected to the source Pcell:4> if the appliedRRCReconfigurationis not due to a conditional reconfiguration execution upon cell selection performed while timer T311 was running, as defined in 5.3.7.3; or4> if the appliedRRCReconfigurationis not received when T316 was running:5> perform the actions for the successful handover report determination as specified in clause 5.7.10.6, upon successfully completing the Random Access procedure triggered for thereconfigurationWithSyncinspCellConfigof the MCG or upon indication from lower layers that the RACH-less handover has been successfully completed for the MCG;

[0137] Fig. 4 is a flow chart that illustrates a proposed method for SPR for RACH-less handover according to an embodiment as disclosed herein. The method includes steps (402-404). In an embodiment, at step (402), the method includes the UE (100) receiving SPR configuration and performing PSCellChange or PS Cell Addition and receiving SPR configuration configured by source PS Cell or target PS Cell.. At step (404), the method includes the UE (100) performing SPR determination upon indication from lower layers that the RACH-less handover has been successfully completed for the SCG.

[0138] In an embodiment, the UE (100) may determine SPR for RACH-less handover upon receiving an indication from lower layers that RACH-less handover has been successfully completed for the SCG.

[0139] In an embodiment, the UE (100) may perform following steps:

[0140] 1.The UE (100) may receive SPR configuration configured by source PS Cell.

[0141] 2. The UE (100) may receive RRCReconfiguration for performing PSCellChange or PS Cell Addition and may receive configuration for performing the PSCellChange or PSCellAddition in a RACH less way. RRCReconfiguration may contain SPR configuration configured by source PS Cell or target PS Cell or PCell.

[0142] 3. The UE (100) may perform PSCellChange or PS Cell Addition.

[0143] 4.The UE (100) performs SPR determination upon indication from lower layers that the RACH-less handover (i.e. PS Cell addition / PS Cell Change without performing random access) has been successfully completed for the SCG.

[0144] In an embodiment, the UE (100) which has determined that SPR needs to be logged for RACH-less handover for SCG (RACH-less PSCellAddition or RACH-less PSCellChange) logs the cell level measurements and beam level measurements of the source PS Cell (in case of PS Cell Change), target PS Cell (in case of PS Cell Addition and PS Cell Change) and the neighbor cells up to the moment the RACH-less handover has been successfully completed. Neighbor cells can be any neighbor cell according to the configured measurement objects. Logging may be performed by UE RRC in NR (or equivalent protocol layer of the UE (100)) in another RAT. UE RRC may consider that RACH-less handover has been successfully completed upon indication from lower layers such as UE MAC.

[0145] There are different options for logging the measurements. Typically, the measurements are logged in reports related to near failure till RRCReconfigurationComplete is send. However, for SPR the UE (100) may send RRCReconfigurationComplete before the RACH-less handover is completed, for e.g. the complete may be send over MCG. i.e. the UE (100) may experience failure even after sending reconfiguration complete and it is helpful for the network optimization to log the measurements till the UE (100) nearly avoid the failure, as indicated by the successful completion of RACH-less handover for SCG (Successful completion of RACH-less handover for SCG is also referred to as Successful completion of PS Cell Addition or PS Cell Change) . Another alternative is to log the measurements at the time of reception of RRC message (RRCReconfiguration including ReconfigurationWithSync) which triggers PSCellChange or PSCellAddition. However, since the network may already have these measurements through other means such as measurement reports, it can log and optimize based on this information. So, it may be helpful if the UE (100) logs the measurements till the indication of successful completion of RACH-less handover for SCG.

[0146] In an embodiment, according to TS 38.331,1> if the UE (100) is configured with E-UTRA nr-SecondaryCellGroupConfig (the UE (100) in (NG)EN-DC):1>elseif the RRCReconfiguration message was received via SRB1 within the nr-SCG within mrdc-SecondaryCellGroup (the UE (100) in NR-DC, mrdc-SecondaryCellGroup was received in RRCReconfiguration or RRCResume via SRB1):2> if the scg-State is not included in the RRCReconfiguration or RRCResume message containing the RRCReconfiguration message:3> perform SCG activation as specified in 5.3.5.13a;3> if reconfigurationWithSync was included in spCellConfig in nr-SCG:4> if the UE (100) was configured with successPSCell-Config when connected to the source PS Cell (for PS Cell change) or to the PCell (for PS Cell addition or change):5> perform the actions for the successful PS Cell change or addition report determination as specified in clause 5.7.10.7, upon successfully completing the Random Access procedure triggered for the reconfigurationWithSync in spCellConfig of the SCG or upon indication from lower layers that the RACH-less handover has been successfully completed for the SCG;1> else if the RRCReconfiguration message was received via SRB3 (the UE (100) in NR-DC):2> if the RRCReconfiguration message was received within DLInformationTransferMRDC:3> if the RRCReconfiguration message was received within the nr-SCG within mrdc-SecondaryCellGroup (NR SCG RRC Reconfiguration):4> if the scg-State is not included in the RRCReconfiguration message containing the RRCReconfiguration message:5> if reconfigurationWithSync was included in spCellConfig in nr-SCG:6> initiate the Random Access procedure on the PS Cell, as specified in TS 38.321 [3];6> if the UE (100) was configured with successPSCell-Config when connected to the source PS Cell (for PS Cell change) or to the PCell (for PS Cell addition or change):7> perform the actions for the successful PS Cell change report determination as specified in clause 5.7.10.7, upon successfully completing the Random Access procedure triggered for the reconfigurationWithSync in spCellConfig of the SCG or upon indication from lower layers that the RACH-less handover has been successfully completed for the SCG;2> else:3> if the RRCReconfiguration includes the reconfigurationWithSync in spCellConfig for the SCG; and3> if the UE (100) was configured with successPSCell-Config when connected to the source PS Cell (for PS Cell change) or to the PCell (for PS Cell addition or change):4> perform the actions for the successful PS Cell change report determination as specified in clause 5.7.10.7, upon successfully completing the Random Access procedure triggered for the reconfigurationWithSync in spCellConfig of the SCG or upon indication from lower layers that the RACH-less handover has been successfully completed for the SCG;

[0147] In an embodiment, the following are the actions for the successful PS Cell change or addition report determination. The UE (100) shall for the PS Cell:

[0148] 1> if the ratio between the value of the elapsed time of the timer T304 and the configured value of the timer T304, included in the last appliedRRCReconfigurationmessage for the SCG including thereconfigurationWithSync, is greater thanthresholdPercentageT304-SCGif included in thesuccessPSCell-Configreceived before executing the last reconfiguration with sync for the SCG; or1> ifsn-InitiatedPSCellChangeassociated to the last appliedRRCReconfigurationwithreconfigurationWithSyncfor the SCG is configured and if the ratio between the value of the elapsed time of the timer T310 and the configured value of the timer T310, configured while the UE (100) was connected to the source PS Cell before executing the last reconfiguration with sync for the SCG, is greater thanthresholdPercentageT310-SCGincluded in thesuccessPSCell-Configif configured by the source PS Cell before executing the last reconfiguration with sync for the SCG; or1> ifsn-InitiatedPSCellChangeassociated to the last appliedRRCReconfigurationwithreconfigurationWithSyncfor the SCG is configured and if the T312 associated to the measurement identity of the target PS Cell was running at the time of initiating the execution of the reconfiguration with sync procedure for the SCG and if the ratio between the value of the elapsed time of the timer T312 and the configured value of the timer T312, configured while the UE (100) was connected to the source PS Cell before executing the last reconfiguration with sync, is greater thanthresholdPercentageT312-SCGincluded in the successPSCell-Configif configured by the source PS Cell before executing the last reconfiguration with sync for the SCG:1> ifsn-InitiatedPSCellChangeassociated to the last appliedRRCReconfigurationwithreconfigurationWithSyncfor the SCG is not configured and if the ratio between the value of the elapsed time of the timer T310 and the configured value of the timer T310, configured while the UE (100) was connected to the source PS Cell before executing the last reconfiguration with sync for the SCG, is greater thanthresholdPercentageT310-SCGincluded in thesuccessPSCell-Configif configured by the PCell before executing the last reconfiguration with sync for the SCG; or1> ifsn-InitiatedPSCellChangeassociated to the last appliedRRCReconfigurationwithreconfigurationWithSyncfor the SCG is not configured and if the T312 associated to the measurement identity of the target PS Cell was running at the time of initiating the execution of the reconfiguration with sync procedure for the SCG and if the ratio between the value of the elapsed time of the timer T312 and the configured value of the timer T312, configured while the UE (100) was connected to the source PS Cell before executing the last reconfiguration with sync, is greater thanthresholdPercentageT312-SCGincluded in the successPSCell-Configif configured by the PCell before executing the last reconfiguration with sync for the SCG:2> clear the information included inVarSuccessPSCell-Report, if any;2> store the successful PS Cell change or addition information inVarSuccessPSCell-Reportand determine the content inVarSuccessPSCell-Reportas follows:3> if the UE (100) is not in SNPN access mode, set theplmn-IdentityListto include the list of EPLMNs (including the RPLMN) stored by the UE (100);3> else if the UE (100) is in SNPN access mode, set thesnpn-IdentityListto include the list of equivalent SNPN identities (including the registered SNPN identity) stored by the UE (100), if available;3> set thepCellIdto the global cell identity and tracking area code, if available, of the PCell;3> for the source PS Cell (in case of PS Cell change procedure) in which the lastRRCReconfigurationmessage for the SCG includingreconfigurationWithSyncwas applied:4> set thesourcePSCellIdinsourcePSCellInfoto the global cell identity and tracking area code, and otherwise to the physical cell identity and carrier frequency of the source PS Cell;4> set thesourcePSCellMeasinsourcePSCellInfoto include the cell level RSRP, RSRQ and the available SINR, of the source PS Cell based on the available SSB and CSI-RS measurements collected up to the moment the UE (100) successfully completed the random access procedure for the SCG or up to the moment the RACH-less handover has been successfully completed for the SCG;4> set thersIndexResultsinsourcePSCellMeasto include all the available SSB and CSI-RS measurement quantities of the source PS Cell collected up to the moment the UE (100) successfully completed the random access procedure for the SCG or up to the moment the RACH-less handover has been successfully completed for the SCG;;3> for the target PS Cell indicated in the last appliedRRCReconfigurationmessage for the SCG includingreconfigurationWithSync:4> set thetargetPSCellIDintargetPSCellInfoto the global cell identity and tracking area code, if available, and otherwise to the physical cell identity and carrier frequency of the target PS Cell;4> set thetargetPSCellMeasintargetPSCellInfoto include the cell level RSRP, RSRQ and the available SINR, of the target PS Cell based on the available SSB and CSI-RS measurements collected up to the moment the UE (100) successfully completed the random access procedure for the SCG or up to the moment the RACH-less handover has been successfully completed for the SCG;;4> set thersIndexResultsintargetPSCellMeasto include all the available SSB and CSI-RS measurement quantities of the target PS Cell collected up to the moment the UE (100) successfully completed the random access procedure for the SCG or up to the moment the RACH-less handover has been successfully completed for the SCG;;4> if the last appliedRRCReconfigurationmessage for the SCG includingreconfigurationWithSyncwas included in the storedcondRRCReconfig:5> set thetimeSinceCPAC-Reconfigto the time elapsed between the initiation of the execution of conditional reconfiguration for the target PS Cell and the reception of the lastconditionalReconfigurationfor the SCG including thecondRRCReconfigof the target PS Cell;3> if triggering threshold for storing the successful PS Cell change or addition information inVarSuccessPSCell-Reportbased on thethresholdPercentageT304-SCGis met:4> sett304-causeinspr-Causetotrue;4> set thera-InformationCommonto include the random-access related information associated to the random access procedure in the target PS Cell, as specified in clause 5.7.10.5;3> if triggering threshold for storing the successful PS Cell change or addition information inVarSuccessPSCell-Reportbased on thethresholdPercentageT310-SCGis met:4> sett310-causeinspr-Causetotrue;3> if triggering threshold for storing the successful PS Cell change or addition information inVarSuccessPSCell-Reportbased on thethresholdPercentageT312-SCGis met:4> sett312-causeinspr-Causetotrue;3> ifsn-InitiatedPSCellChangeassociated to the last appliedRRCReconfigurationwithreconfigurationWithSyncfor the SCG is configured:4> consider allmeasObjectNRconfigured by the source PS Cell;3> else:4> consider allmeasObjectNRconfigured by the PCell;3> for each of the consideredmeasObjectNR:4> if measurements are available for themeasObjectNR:5> if the SS / PBCH block-based measurement quantities are available:6> include in themeasResultListNRinmeasResultNeighCellsall the available measurement quantities of the best measured cells, other than the source PS Cell (in case of PS Cell change procedure) or target PS Cell, ordered such that the cell with highest SS / PBCH block RSRP is listed first if SS / PBCH block RSRP measurement results are available, otherwise the cell with highest SS / PBCH block RSRQ is listed first if SS / PBCH block RSRQ measurement results are available, otherwise the cell with highest SS / PBCH block SINR is listed first, based on the available SS / PBCH block based measurements collected up to the moment the UE (100) successfully completed the random access procedure or up to the moment the RACH-less handover has been successfully completed for the SCG;;6> for each neighbour cell included, include the optional fields that are available (including the CSI-RS based measurement quantities, if available);5> if the CSI-RS measurement quantities are available for the cells not yet included inmeasResultListNRinmeasResultNeighCells:6> include in themeasResultListNRinmeasResultNeighCellsall the available measurement quantities of the best measured cells, other than the source PS Cell (in case of PS Cell change procedure) and target PS Cell, ordered such that the cell with highest CSI-RS RSRP is listed first if CSI-RS RSRP measurement results are available, otherwise the cell with highest CSI-RS RSRQ is listed first if CSI-RS RSRQ measurement results are available, otherwise the cell with highest CSI-RS SINR is listed first, based on the available CSI-RS based measurements collected up to the moment the UE (100) successfully completed the random access procedure or up to the moment the RACH-less handover has been successfully completed for the SCG;6> for each neighbour cell included, include the optional fields that are available;

[0149] In an embodiment, the UE (100) may determine SPR for RACH-less handover upon receiving the downlink assignment on the PDCCH for the MAC entity's C-RNTI after the first PUSCH transmission to the Serving Cell of the SCG.

[0150] In an embodiment, the UE (100) may determine SPR for RACH-less handover upon receiving the uplink grant on the PDCCH for the MAC entity's C-RNTI after the first PUSCH transmission to the Serving Cell of the SCG.

[0151] In an embodiment, the UE (100) may determine SPR for RACH-less handover upon receiving the uplink grant for a new transmission on the same HARQ process used for the first PUSCH transmission to the Serving Cell of the SCG.

[0152] In an embodiment, the UE (100) which encountered Radio Link Failure (RLF) or LTM cell switch failure or conditional LTM cell switch failure and has performed LTM based recovery (i.e. has applied LTM candidate configuration based on configuration such as attemptLTM-Switch in NR) and has further encountered LTM cell switch failure (while attempting the LTM based recovery) and has further selected an Inter-RAT cell (such as E-UTRA cell in LTE or NR Cell in case of LTM cell switch or equivalent procedure in 6G) after the recovery (the UE (100) may logs the ltm-RecoveryCellId and the failedPCellId in this scenario. failedPCellId is the cell where the radio link failure or handover failure or LTM cell switch failure or conditional LTM cell switch failure occurred. ltm-RecoveryCellId is the cell where the UE attempted LTM based recovery) and further received the RRC message to setup connection (such as RRCConnectionSetup in E-UTRA or RRC Setup in NR) logs the time from the radio link failure or LTM cell switch failure which has occurred before performing LTM based recovery (i.e. time from the first failure) till the reception of the RRC message to setup connection in RLF report. This helps the network to identify the configuration for the UE (100) when the first RLF occurred and optimize the same. The second RLF can be averted if the first RLF is avoided and so the UE (100) reports required information according to this embodiment. Logging the time from first RLF to the time the RRC connection is successfully setup helps the network to identify the severity of radio link failure. During this time, the UE (100) can not transmit or receive user data. So, if the time is large, it means that the issue is severe. The network need to prioritize fixing this scenario. However in the existing art, the UE logs the time from the nearest LTM cell switch failure to the RRCConnectionSetup.

[0153] In an embodiment, the UE (100) which encountered Radio Link Failure (RLF) or LTM cell switch failure or conditional LTM cell switch failure and has performed LTM based recovery (i.e. has applied LTM candidate configuration based on configuration such as attemptLTM-Switch in NR) and has further encountered LTM cell switch failure (while attempting the LTM based recovery) and has further selected an Inter-RAT cell (such as E-UTRA cell in LTE or NR Cell in case of LTM cell switch or equivalent procedure in 6G) after the recovery (the UE (100) may logs the ltm-RecoveryCellId in this scenario) and further received the RRC message to resume connection (such as RRCResume in NR) logs the time from the radio link failure or LTM cell switch failure which has occurred before performing LTM based recovery (i.e. time from the first failure) till the reception of the RRC message to resume connection in RLF report. This helps the network to identify the configuration for the UE (100) when the first RLF occurred and optimize the same. The second RLF can be averted if the first RLF is avoided and so the UE (100) reports required information according to this embodiment.

[0154] According to an embodiment, at step 1, MCG RLF occurs at the UE (100) or LTM cell switch failure occurs at the UE (100). At step 2, the UE (100) log the RLF report. At step 3, the UE (100) selects an LTM candidate cell while timer T311 is running and performs LTM based recovery. At step 4, the UE (100) faces LTM cell switch failure such as T304 timer expiry. At step 5, the UE (100) selects a E-UTRA cell. At step 6, if the UE (100) supports RLF report for LTM, the UE (100) logs the time from the MCG RLF in step 1 when RRCConnectionSetup is received.

[0155] According to an example embodiment, based on TS 36.331;

[0156] The UE (100) shall:

[0157] 1> except for NB-IoT:2> if the UE (100) supports RLF report for inter-RAT MRO EUTRA as defined in TS 38.306

[0087] , and if the UE (100) has radio link failure or handover failure information available inVarRLF-Reportof TS 38.331

[0082] and if the RPLMN is included inplmn-IdentityListstored inVarRLF-Reportof TS 38.331

[0082] :3> ifreconnectCellIdinVarRLF-Reportof TS 38.331

[0082] is not set, and if the UE (100) failed to perform reestablishment; or3> ifreconnectCellIdinVarRLF-Reportof TS 38.331

[0082] is not set, and if the UE (100) selected the current PCell immediately after failure in performingMobilityFromNRCommand:4> if the selected PCell is an acceptable cell as defined in TS 36.304 [4]:5> settimeUntilReconnectioninVarRLF-Reportof TS 38.331

[0082] to the time that elapsed since theMobilityFromNRCommandfailure;4> if the selected PCell is a suitable cell as defined in TS 36.304 [4]:5> if the UE (100) supports RLF-Report for conditional handover as defined in TS 38.306

[0087] and ifchoCellIdinVarRLF-Reportof TS 38.331

[0082] is set or;5> if the UE (100) supports RLF-Report for LTM as defined in TS 38.306 and ifltm-RecoveryCellIdinVarRLF-Reportof TS 38.331

[0082] is set:6> settimeUntilReconnectioninVarRLF-Reportof TS 38.331

[0082] to the time that elapsed since the radio link failure or handover failure experienced in thefailedPCellIDstored inVarRLF-Reportof TS 38.331

[0082] ;5> else:6> set timeUntilReconnection inVarRLF-Reportof TS 38.331

[0082] to the time that elapsed since the last radio link failure or handover failure;

[0158] Fig. 5 is a flow diagram that illustrates a method for handling SCG failure in a wireless communication system according to an embodiment as disclosed herein. The method includes steps (502-506). Each step is explained in further detail below.

[0159] At step (502), the method includes detecting by the UE (100) whether the UE (100) supports SCG failure in an EN-DC or a NGEN-DC. EN-DC and NGEN-DC are 5G non-standalone (NSA) features allowing the UE (100) to connect simultaneously to 4G LTE and 5G NR networks.

[0160] At step (504), the method includes setting by the UE (100) an IE to indicate random access procedure related information associated with the UE (100). The IE is set when the UE (100) supports SCG failure. The random access procedure related information includes information about each random access attempt performed by the UE (100) arranged in a chronological order. The IE is a 'perRA-InfoListNR', which is a sequence of octet strings in a NR format. The octet strings includes information of a type including at least one of a type PerRAInfoList-r16, a PerRAInfoList-v1660, and a PerRAInfoList-v1840. At step (506), the method includes transmitting by the UE (100) the IE to the network apparatus.

[0161] Fig. 6 is a flow diagram that illustrates a method for handling SCG failure due to a reconfiguration with sync according to an embodiment as disclosed herein, The method includes steps (602-604). Each step is explained in further detail below.

[0162] At step (602), the method includes detecting by the UE (100) whether the SCG failure is due to a reconfiguration with sync failure. The reconfiguration with sync occurs when the UE (100) fails to synchronize with a target cell within the allowed time, or fails to complete the random access procedure after receiving a reconfiguration message (RRCConnectionReconfiguration). The reconfiguration with sync failure indicates a failed radio handover, often due to degraded radio links or incorrect, contradictory, or large configuration messages, resulting in a handover failure, radio link failure, or SCG failure.

[0163] At step (604), the method includes adding by the UE (100) random access information related to reconfiguration with sync in a SCG failure information NR. This information is added when the SCG failure is due to the reconfiguration with sync failure. The SCG failure information NR includes a random access (RA) report or per-RA info list related to the reconfiguration with sync.

[0164] Fig. 7 is a flow diagram that illustrates a method for handling RLF reports in a wireless communication system according to an embodiment as disclosed herein. The method includes steps (702-714). Each step is explained in further detail below.

[0165] At step (702), the method includes detecting by the UE (100) at least one of a radio link failure (RLF), a handover failure, a LTM cell switch failure, and a conditional LTM cell switch failure. The RLF refers to a diagnostic message sent by the UE (100) to the network apparatus after a connection loss, used for network optimization and troubleshooting. The RLF contains details about the failure cause (e.g., handover failure, beam failure), radio measurements like RSRP, RSRQ, and CQI, assisting in diagnosing coverage issues or handover problems.

[0166] At step (704), the method includes applying by the UE (100) a LTM candidate configuration based on a configuration from a network apparatus for recovery and logging LTM recovery cell ID . At step (706), the method includes detecting by the UE (100) whether the LTM cell switch based on the application has failed.

[0167] At step (708), the method includes selecting by the UE (100) an E-UTRA cell and attempting to setup a RRCConnection in an E-UTRA. At step (710), the method includes receiving by the UE (100) a RRCConnectionSetup from the network apparatus. The RRCconnectionsetup refers to when the UE (100) transitions from an idle to a connected state, establishing an initial radio signaling link (SRB1) between the UE (100) and the network. The RRCconnectionsetup enables data transmission, configures initial physical channels (PUSCH, PUCCH), and assigns a unique C-RNTI to the UE (100).

[0168] At step (712), the method includes detecting by the UE (100) whether the UE (100) supports the RLF report for LTM and whether an LTM cell ID within the RLF report is set. At step (714), the method includes setting the 'timeUntilReconnection' in the RLF report to a time elapsed since the RLF or a handover failure occurs on the failed PCell. The ID of the failed PCell is stored as a 'failedPCellID' in the RLF report. A time difference between the RLF in a failedPCell and the RRCConnectionSetup is logged.

[0169] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

1.A method performed by a user equipment (UE) in a wireless communication system, the method comprising:identifying whether the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC);in case that the UE supports the SCG failure information for the EN-DC or the NGEN-DC, setting an information element (IE) in the SCG failure information, wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC; andtransmitting, to a network apparatus, the SCG failure information including the IE.2.The method of claim 1, wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format.3.The method of claim 2, wherein the octet strings includes information of a type comprising at least one of a type PerRAInfoList-r16, a PerRAInfoList-v1660, and a PerRAInfoList-v1840.4.The method of claim 1, comprising:identifying whether the SCG failure information is due to a reconfiguration with sync failure; andin case that the SCG failure information is due to the reconfiguration with sync failure, adding random access information related to reconfiguration with sync in an SCG failure information NR, wherein the SCG failure information NR includes a random access report or per-RA info list related to the reconfiguration with sync.5.The method of claim 1, wherein the random access procedure related information includes information on each random access attempt performed by the UE arranged in a chronological order.6.A method performed by a network apparatus in a wireless communication system, the method comprising:transmitting, to a user equipment (UE), a radio resource control (RRC) reconfiguration message including information associated with a secondary cell group (SCG) failure; andin case that the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC), receiving, from the UE, an SCG failure information including an information element (IE), wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC,wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format.7.The method of claim 6, wherein the octet strings includes information of a type comprising at least one of a type PerRAInfoList-r16, a PerRAInfoList-v1660, and a PerRAInfoList-v1840.8.The method of claim 6, wherein the random access procedure related information includes information on each random access attempt performed by the UE arranged in a chronological order.9.A user equipment (UE) in a wireless communication system, the UE comprising:memory storing instructions; andprocessing circuitry coupled to the memory and configured, based at least partially on execution of the instructions, to cause the UE to:identify whether the UE supports a secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC);in case that the UE supports the SCG failure information for the EN-DC or the NGEN-DC, set an information element (IE) in the SCG failure information, wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC; andtransmit, to a network apparatus, the SCG failure information including the IE.10.The UE of claim 9, wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format.11.The UE of claim 10, wherein the octet strings includes information of a type comprising at least one of a type PerRAInfoList-r16, a PerRAInfoList-v1660, and a PerRAInfoList-v1840.12.The UE of claim 9, wherein the processing circuitry causes the UE to:identify whether the SCG failure information is due to a reconfiguration with sync failure; andin case that the SCG failure information is due to the reconfiguration with sync failure, add random access information related to reconfiguration with sync in an SCG failure information NR, wherein the SCG failure information NR includes a random access report or per-RA info list related to the reconfiguration with sync.13.The UE of claim 9, wherein the random access procedure related information includes information on each random access attempt performed by the UE arranged in a chronological order.14.A network apparatus in a wireless communication system, the network apparatus comprising:memory storing instructions; andprocessing circuitry coupled to the memory and configured, based at least partially on execution of the instructions, to cause the network apparatus to:transmit, to a user equipment (UE), a radio resource control (RRC) reconfiguration message including information associated with a secondary cell group (SCG) failure; andin case that the UE supports secondary cell group (SCG) failure information for an evolved universal terrestrial radio access (E-ULTRA)-new radio (NR) dual connectivity (EN-DC) or a next generation (NGEN)-dual connectivity (NGEN-DC), receive, from the UE, an SCG failure information including an information element (IE), wherein the IE indicates a random access procedure related information associated with the UE which has experienced an SCG failure in the EN-DC or the NGEN-DC,wherein the IE is a 'perRA-InfoListNR', which is a sequence of octet strings in an NR format.15.The method of claim 6, wherein the octet strings includes information of a type comprising at least one of a type PerRAInfoList-r16, a PerRAInfoList-v1660, and a PerRAInfoList-v1840.

Images