Method and apparatus for performing self-optimisation in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments herein disclose a method for handling a data transmission information in a wireless network (300) by a UE (100). The method includes evaluating whether an SDT can be performed. Further, the method includes determining whether the SDT is a MO SDT. Further, the method includes determining whether a SDT data volume to be reported is above a predefined value based on the determination. In an embodiment, the method includes reporting an actual SDT data volume to a network entity (200) upon determining that the SDT data volume to be reported is not above the predefined value. In an embodiment, the method includes reporting a predefined SDT data volume to the network entity (200) upon determining that the SDT data volume to be reported is above or equal to the predefined value.

Description

METHOD AND APPARATUS FOR PERFORMING SELF-OPTIMISATION IN A WIRELESS COMMUNICATION SYSTEM

[0001] Embodiments disclosed herein relate to wireless communication networks (or wireless networks), and more particularly to methods and systems for reporting optimization information related to Small Data Transmission (SDT) information and Non Terrestrial Network (NTN) Information for Self-Organizing Networks (SON) / Minimization of Drive Tests (MDT) in New Radio (NR) and other wireless technologies.

[0002] 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 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz 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.

[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 MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, 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 BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[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 V2X (Vehicle-to-everything) 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, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[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, IAB (Integrated Access and Backhaul) 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 DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step 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 that have been exponentially increasing will be connected to communication networks, and it is accordingly 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 AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction 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 not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also 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 (Artificial Intelligence) 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] Embodiments of the present disclosure is to provide an apparatus and method for effectively providing a service in a wireless communication system.

[0009] In an embodiment, a method performed by a user equipment (UE) in a wireless communication system is provided. The method includes: receiving, from a base station, a UE information request message; setting a random access report list in a UE information response message; and transmitting, to the base station, the UE information response message. The random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.

[0010] In an embodiment, a method performed by a base station in a wireless communication system is provided. The method includes: transmitting, to a user equipment (UE), a UE information request message; and receiving, from the UE, a UE information response message including a random access report list. The random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.

[0011] In an embodiment, a user equipment (UE) in a wireless communication system is provided. The UE includes at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the UE to receive, from a base station, a UE information request message, set a random access report list in a UE information response message, and transmit, to the base station, the UE information response message. The random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.

[0012] In an embodiment, a base station in a wireless communication system is provided. The base station includes at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the base station to transmit, to a user equipment (UE), a UE information request message, and receive, from the UE, a UE information response message including a random access report list. The random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.

[0013] Accordingly, the embodiments disclosed herein relate to a method for handling a data transmission information in a wireless network. The method includes evaluating, by a UE, whether a SDT can be performed. Further, the method includes determining, by the UE, whether the SDT is a MO SDT. Further, the method includes determining, by the UE, whether a SDT data volume to be reported is above a predefined value based on the determination. In an embodiment, the method includes reporting an actual SDT data volume to a network entity upon determining that the SDT data volume to be reported is not above the predefined value. In an embodiment, the method includes reporting a predefined SDT data volume to the network entity upon determining that the SDT data volume to be reported is above or equal to the predefined value.

[0014] Accordingly, the embodiments disclosed herein relate to a method for handling a data transmission information in a wireless network. The method includes receiving, by a network entity: one of: reporting of an actual SDT data volume from a UE upon determining that the SDT data volume to be reported is not above a predefined value at the UE, and reporting a predefined SDT data volume from the UE upon determining that the SDT data volume to be reported is above or equal to the predefined value at the UE. Further, the method includes handling, by the network entity, at least one of: a Self-Organizing Network (SON) purpose and a Minimization of Drive Tests (MDT) purpose for a MO SDT based on one of: the actual SDT data volume and the predefined SDT data volume.

[0015] Accordingly, the embodiments disclosed herein relate to a UE including a SDT data volume handling controller coupled with a processor and a memory. The SDT data volume handling controller is configured to evaluate whether a SDT can be performed. Further, the SDT data volume handling controller is configured to determine that the SDT is a MO SDT. Further, the SDT data volume handling controller is configured to determine whether a SDT data volume to be reported is above a predefined value based on the determination. In an embodiment, the SDT data volume handling controller is configured to report an actual SDT data volume to a network entity upon determining that the SDT data volume to be reported is not above the predefined value. In another embodiment, the SDT data volume handling controller is configured to report a predefined SDT data volume to a network entity upon determining that the SDT data volume to be reported is above or equal to the predefined value.

[0016] Accordingly, the embodiments disclosed herein relate to a network entity including a SDT data volume handling controller coupled with a processor and a memory. The SDT data volume handling controller is configured to receive one of: report of an actual SDT data volume from a UE upon determining that the SDT data volume to be reported is not above a predefined value at the UE, and report a predefined SDT data volume from the UE upon determining that the SDT data volume to be reported is above or equal to the predefined value at the UE. Further, the SDT data volume handling controller is configured to handle at least one of: a SON purpose and an MDT purpose for a MO SDT based on one of: the actual SDT data volume and the predefined SDT data volume.

[0017] In an embodiment, the predefined value is 96000 bytes.

[0018] In an embodiment, the UE does not report the SDT data volume when a random access is initiated due to a mobile terminated (MT) SDT. In an embodiment, a SDT data volume field indicates a buffered data volume in the UE for a radio bearer configured for the SDT during evaluation of SDT procedure.

[0019] In an embodiment, a data radio bearer (DRB) is considered for the SDT data volume reporting when the DRB is part of a sdt-DRB-List-r17 received from the network entity.

[0020] In an embodiment, a Signaling Radio Bearer 2 (SRB2) is considered for the SDT data volume reporting when a sdt-SRB2-Indication-r17 received from the network entity is set as true.

[0021] In an embodiment, the SDT data volume is reported in a Random Access (RA) report.

[0022] In an embodiment, the UE reports zero as SDT data volume, upon determining there is no available data across all RBs configured for the SDT when the UE evaluates that the UE performs the SDT.

[0023] In an embodiment, the SDT data volume is reported when the SDT has failed.

[0024] In an embodiment, the UE reports the SDT data volume to the network entity for at least one of: a Self-Organizing Network (SON) purpose and a Minimization of Drive Tests (MDT) purpose for the MO SDT.

[0025] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the scope thereof, and the embodiments herein include all such modifications.

[0026] The principal object of the embodiments herein is to provide a method and a UE for reporting SDT information for SON / MDT in a wireless network.

[0027] Another object of embodiments herein is to evaluate whether a SDT can be performed.

[0028] Another object of embodiments herein is to determine that the SDT is a mobile originated (MO) SDT.

[0029] Another object of embodiments herein is to determine whether a SDT data volume to be reported is above a predefined value based on the determination.

[0030] Another object of embodiments herein is to report an actual SDT data volume to a network entity upon determining that the SDT data volume to be reported is not above the predefined value.

[0031] Another object of embodiments herein is to report a predefined SDT data volume to a network entity upon determining that the SDT data volume to be reported is above or equal to the predefined value.

[0032] Another object of embodiments herein is to enable the UE and the network entity for handling a RLF due to expiry of a t-service.

[0033] Another object of embodiments herein is to enable the UE to report tracking area information in an NTN cell in SON / MDT reports.

[0034] Another object of embodiments herein is to enable the UE to provide information (i.e., network receives information) for optimizing conditional handovers in the NTN.

[0035] Embodiments herein 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 following illustratory drawings. Embodiments herein are illustrated by way of examples in the accompanying drawings, and in which:

[0036] FIG. 1 depicts a process of providing information to aid a wireless network for self-optimization, according to existing arts;

[0037] FIG. 2 depicts an NTN release 17 architecture and scenario in a wireless network, according to existing arts;

[0038] FIG. 3 illustrates an overview of a wireless network, according to embodiments as disclosed herein;

[0039] FIG. 4 shows various hardware components of a UE, according to the embodiments as disclosed herein;

[0040] FIG. 5 shows various hardware components of a network entity, according to the embodiments as disclosed herein;

[0041] FIG. 6 is a flow chart illustrating a method, implemented by the UE, for handling a data transmission information in the wireless network, according to the embodiments as disclosed herein;

[0042] FIG. 7 is a flow chart illustrating a method, implemented by the network entity, for handling the data transmission information in the wireless network, according to the embodiments as disclosed herein;

[0043] FIG. 8 is an example flow diagram illustrating a method of reporting a SDT data volume to the network entity, according to embodiments as disclosed herein;

[0044] FIG. 9 is an example sequence diagram that illustrates a method of reporting the SDT data volume to a gNB, according to embodiments as disclosed herein;

[0045] FIG. 10 depicts a process of logging t-Service information in SON / MDT reports, according to embodiments as disclosed herein;

[0046] FIG. 11 depicts a process of logging t-Service information in RLF reports, according to embodiments as disclosed herein;

[0047] FIG. 12 depicts the process of logging tracking area information in SON / MDT reports, according to embodiments as disclosed herein; and

[0048] FIG. 13 depicts a method for performing SON / MDT reporting with conditional event configuration for NTN, according to embodiments as disclosed herein.

[0049] It may be noted that to the extent possible, like reference numerals have been used to represent like elements in the drawing. Further, those of ordinary skill in the art will appreciate that elements in the drawing are illustrated for simplicity and may not have been necessarily drawn to scale. For example, the dimension of some of the elements in the drawing may be exaggerated relative to other elements to help to improve the understanding of aspects of the invention. Furthermore, the elements may have been represented in the drawing by conventional symbols, and the drawings may show only those specific details that are pertinent to the understanding the embodiments of the invention so as not to obscure the drawing with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

[0050] 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. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0051] The words / phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.", "i.e.", are merely used herein to mean "serving as an example, instance, or illustration. Any embodiment or implementation of the present subject matter described herein using the words / phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.", "i.e." is not necessarily to be construed as preferred or advantageous over other embodiments.

[0052] Embodiments herein may be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which may be 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 may optionally be driven by a firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more 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 may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

[0053] It should be noted that elements in the drawings are illustrated for the purposes of this description and ease of understanding and may not have necessarily been drawn to scale. For example, the flowcharts / sequence diagrams illustrate the method in terms of the steps required for understanding of aspects of the embodiments as disclosed herein. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Furthermore, in terms of the system, one or more components / modules which comprise the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0054] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any modifications, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings and the corresponding description. Usage of words such as first, second, third etc., to describe components / elements / steps is for the purposes of this description and should not be construed as sequential ordering / placement / occurrence unless specified otherwise.

[0055] A fifth generation (5G) new radio (NR) access network also known as NG-RAN (Next Generation Radio Network) comprises of a number of NR base stations (known as gNBs). The gNBs can be connected to each other through an Xn interface, and will be connected to various core network elements like AMF (Access and Mobility Management Function) entity, UPF (User Plane Function) entity etc. Further, the gNBs can be divided into two physical entities; i.e., CU (Centralized Unit) and DU (Distributed Unit). The CU provides support for higher layers of the protocol stack, such as SDAP (Session Data Application Protocol), PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control). the DU provides support for lower layers of the protocol stack such as RLC (Radio Link Control), MAC (Medium Access Control) and Physical layer.

[0056] Each gNB can have multiple cells serving many UEs (User Equipment). There are a large number of techniques and configuration parameters used in the NG-RAN. It can be 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 optimal parameters. However, such manual parameter tuning is a costly operation since the manual parameter tuning 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, Third Generation Partnership Project (3GPP) has introduced Self-Organizing Networks (SON) techniques in the wireless technologies like NR. The SON techniques was first introduced in 3GPP release 9, in a Long Term Evolution (LTE). The SON solutions can be divided into three categories such as Self-Configuration, Self-Optimization and Self-Healing. A SON architecture can be a centralized, distributed or a hybrid solution. Mobility Robustness Optimization (MRO) is the SON technique which is used to optimize various parameters related to mobility.

[0057] According to 3GPP specifications like technical specification (TS) 38.300, the MRO aims at detecting and enabling correction of the following problems:

[0058] a) Connection failure due to intra-system or inter-system mobility,

[0059] b) Inter-system Unnecessary HO (too early inter-system HO from NR to Evolved Universal Terrestrial Radio Access Network (E-UTRAN) with no radio link failure), and

[0060] c) Inter-system HO ping-pong.

[0061] The MRO provides a means to distinguish the above problems from NR coverage related problems and other problems, not related to mobility. For analysis of connection failures, the UE makes the Radio Link Failure (RLF) Report available to the network. The UE stores a latest RLF Report, including both LTE and NR RLF report until the RLF report is fetched by the network or for 48 hours after the connection failure is detected.

[0062] One of the functions of Mobility Robustness Optimization in NR R17 is to detect connection failures that occurred due to Too Early or Too Late inter-system handovers. These problems are defined as follows:

[0063] a) Inter-system / Too Late Handover: The RLF occurs after the UE has stayed in a cell belonging to an NG-RAN node for a long period of time and the UE attempts to re-connect to a cell belonging to an E-UTRAN node.

[0064] b) Inter-system / Too Early Handover: The RLF occurs shortly after a successful handover from a cell belonging to an E-UTRAN node to a target cell belonging to an NG-RAN node. The UE attempts to re-connect to the source cell or to another cell belonging to an E-UTRAN node.

[0065] One of the purposes of inter-system Mobility Robustness Optimization in the NR R17 is the detection of a non-optimal use of network resources. In particular, in case of inter-system operations and when the NR is considered, the case known as unnecessary HO to another system is identified. The problem is defined as follows:

[0066] a) The UE is handed over from the NR to the E-UTRAN even though the quality of the NR coverage was sufficient for a service used by the UE. The handover may therefore be considered as unnecessary HO to another system (i.e. Evolved Packet System (EPS)) (too early inter-system HO without connection failure).

[0067] In inter-system HO, if the serving cell threshold (NR cell) is set too high, and cell in another system (i.e. EPS) with good signal strength is available, a handover to another system may be triggered unnecessarily, resulting in an inefficient use of the networks. With a lower threshold the UE could have continued in a source system (i.e., 5GS).

[0068] One of the functions of Mobility Robustness Optimization is to detect ping-pongs that occur in the inter-system environment. The problem is defined as follows:

[0069] a) The UE is handed over from a cell in a source system (e.g. 5GS) to a cell in a target system different from the source system (e.g. EPS), then within a predefined limited time the UE is handed over back to a cell in the source system, while the coverage of the source system was sufficient for the service used by the UE. The event may occur more than once.

[0070] The UE may report some information to aid the network for the self-optimization. These can be reported through the use of a UE assistance information reporting. The network is further indicated that the UE has this information through indicating their existence in a number of RRC-Completemessages (such asRRCReestablishmentComplete,RRCReconfigurationComplete,RRCResumeCompleteandRRCSetupComplete). This procedure can be seen in FIG. 1.

[0071] As shown in FIG. 1, at step 1a, the UE (100) detects at least one of: the RLF Report, the handover failure report, the Successful Handover report and the Successful PSCell Change Report. At step 1b, measurements are performed at the UE (100).

[0072] At step 2, the UE (100) performs an RRC procedure comprising at least one of, an RRC set up, an RRC reestablishment and an RRC resume. At step 3, the UE (100) transmits an RRC complete message to a network enetity (e.g., gNB (200a)), where the measurements for self-optimization of the network entity (200) can be available to share with the network entity (200) after completion of the RRC procedure. At step 4, the gNB (200a) transmits a request for the measurement information to the UE (100). At step 5, the UE (100) provides the requested measurement information to the gNB (200a).

[0073] The SON / MDT repots (e.g. RLF Report, Successful Handover report and Successful PSCell Change Report) may all be sent over the Xn to the neighbour gNBs. The RLF report is sent in an Xn message FAILURE INDICATION, the Successful Handover Report and Successful PSCell Change Report are sent in the ACCESS and MOBILITY INDICATION.

[0074] Connection establishment reporting:The UE connection establishment failure report provides details on failed RRC setup or RRC resume attempts. The UE connection establishment failure report contains the following information:

[0075] a. Measurements of the failed cell,

[0076] b. UE location information,

[0077] c. Measurements of neighbouring cells,

[0078] d. Number of connection establishment failures,

[0079] e. Random access information (a list of random access information) and

[0080] f. Time since the failure

[0081] Radio Link Failure Reporting:Radio Link Failure procedures are introduced to allow the UE (100) to regain its radio link in case the radio link fails. After having been triggered, the UE (100) performs RRC re-establishment, which means that the UE (100) performs cell selection to potentially find the new cell (the same cell is a possible outcome) and connects to the cell.

[0082] The Radio Link Failure can be declared in a number of cases. Some examples are:

[0083] a) UE out of sync

[0084] - The UE (100) 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 (100) triggers a timer (T310) for the UE (100) to recover. If it does not recover, the UE (100) declares the RLF.

[0085] - The recover condition is that the UE (100) receives an in-sync indication a configurable number of times (N311) during the T310 timer duration. This can be seen in Figure 2b.

[0086] b) RLC PDUs are re-transmitted a number of times

[0087] - The network entity (200) configures a number of times (maxRetxThreshold) that an RLC PDU may be attempted to be re-transmitted.

[0088] c) Random access problems

[0089] - This can occur when the UE (100) is in connected mode and the UE (100) is trying to re-synchronize, for instance after losing uplink synchronization.

[0090] d) Backhaul (BH) RLF (IAB related)

[0091] - Failure of backhaul links

[0092] e) Uplink Listen Before Talk (LBT) failure

[0093] - This is when the UE (100) fails LBT when on unlicensed band.

[0094] Although, the handover failure does cause the UE (100) to declare the 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. The RLF report may comprise of the following information:

[0095] a. Measurements of serving and neighbouring cell,

[0096] b. A Cell Radio Network Temporary Identifier (C-RNTI) used by the UE (100),

[0097] c. The previous Cell ID,

[0098] d. The failed Cell ID,

[0099] e. The reconnect cell ID,

[0100] f. Time until reconnection,

[0101] g. Reestablishment of cell ID,

[0102] h. Time of connection failure,

[0103] i. Time since the failure,

[0104] j. Connection failure type - RLF or a Handover Failure,

[0105] k. RLF cause - t310 expiry (receiving lower layer out-of-sync indications), random access problem, RLC maximum number of retransmissions, beam failure recovery, LBT, Integrated Access and Backhaul (IAB) backhaul radio link failure, T312 expiry,

[0106] l. Location info of the UE,

[0107] m. No suitable cell found,

[0108] n. Random access information,

[0109] o. Handover type - Conditional Handover (CHO) or Dual Active Protocol Stack (DAPS),

[0110] p. Time since CHO reconfiguration or DAPS failure

[0111] q. E-UTRA RLF report including E-UTRA measurement result and cell ID of E-UTRA cell,

[0112] r. CHO information such as CHO cell ID and CHO candidate cell list

[0113] s. Master cell group (MCG) failure causes - T316 expiry or Secondary Cell Group (SCG) deactivation,

[0114] t. SCG failure causes - same as RLF cause,

[0115] u. Time elapsed since SCG failure,

[0116] v. Voice fallback handover,

[0117] w. RSSI serving and neighbour cell measurement results and

[0118] x. BWP info

[0119] When the RLF is for SCG, the UE (100) may include the information for SON / MDT in SCGFailureInformation.

[0120] Successful Handover report:The successful handover report (SHR) gives the network entity (200) awareness of information when the handover is successful. This may for instance give the network related potential information even when the handover is successful, as even though the handover is successful does not mean that it is entirely unproblematic as the handover may take a long time to complete.

[0121] The successful handover report contains the following information:

[0122] a. Source and target cell info,

[0123] b. Measurement of neighbouring cells,

[0124] c. UE location information,

[0125] d. Time since CHO reconfiguration,

[0126] e. SHR cause - T304, T310, T312. This tells the network entity (200) the reason why the SHR was triggered. The triggering may be based on the timer have elapsed more than a certain percentage,

[0127] f. Random access information,

[0128] g. User plane interruption time during the handover,

[0129] h. C-RNTI,

[0130] i. E-UTRA information such as target cell ID and E-UTRA C-RNTI, and

[0131] j. Time since SHR.

[0132] Another type of Successful report is the Successful PSCell Change (or addition) report (SPR). It contains similar information to report when the UE (100) performs either a successful addition of an SCG, or changing the PSCell of the SCG.

[0133] Random access report:The random access report is provided to enable the network entity (200) to identify issues with random access for instance enable the network to optimize and reconfigure its random access configuration. For instance, provide more random access resources, provide more resilient random access formats, increase the number of allowed attempts or increase timers. Similarly, if all random access attempts are successful the network entity (200) may reduce the random access resources.

[0134] The random access report list contains the following information:

[0135] a. Cell ID with which the random access was performed,

[0136] b. Purpose of the random access attempt - access related, BFR, reconfiguration with sync, uplink being unsynchronized, SR failure or no uplink resources, system information request via RACH or via msg3 or listen-before-talk failure,

[0137] c. Random access Information Common - This contains more details such as frequency, subcarrier spacing, bandwidth, random access configuration, DL pathloss etc., and

[0138] d. This also contains the per-random access attempt list which contains how many preamble attempts were performed and the SSB index of the attempts.

[0139] Non-Terrestrial Network:NR NTN (NR_NTN_solutions-Core) [RP-211557] was a 3GPP Work Item in 3GPP Release 17 to define solution enable New Radio (NR) and NG-RAN support Non-Terrestrial Networks. It addressed solution for Transparent payload for both Geostationary and non-Geostationary network scenarios, with the UE (100) having Global Navigation Satellite System (GNSS) capability and the satellite beams being earth-fixed and / or earth-moving.

[0140] FIG. 2 depicts an NTN release 17 architecture and scenario in the wireless network (300). The wireless network (300) includes a network entity (200) (example a gNB), a core network (130), a gateway (140), an NTN cell (150), the UE (100), and a satellite (170), where the gateway (140) facilitates a wireless link (e.g., feeder link) between the network entity (200) and the satellite (170). The network entity (200) is establishing a communication channel through an Access link for data communication.

[0141] An internet of things (IoT) NTN was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN IoT devices (e.g., NB-IoT and LTE-M / eMTC) [RP-202689]. The NR NTN was a work item in Rel-17 to specify adaptation to allow NR to function over NTN [RP-211557]. The Non-Terrestrial Network access may be served via satellites that are in Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS).

[0142] Following the Work items in Release 17 there were work items to enhance NR NTN [RP-220953] and IoT NTN [RP-220979] in Release 18. NR NTN phase 3 [RP-234078] is a 3GPP Work Item in 3GPP Release 19 aiming to enhance NR NTN with a range of enhancements:

[0143] a. Downlink coverage enhancements,

[0144] b. Uplink capacity and throughput enhancements by using Orthogonal Coverage Codes,

[0145] c. MBS broadcast over NTN,

[0146] d. Introduction of regenerative payload,

[0147] e. Redcap and NTN enhancements, and

[0148] f. Terrestrial E-UTRAN to NR NTN mobility

[0149] NTN system information:As the NTN has a number of NTN-specific information elements that are only required when accessing an NTN cell, and also due to the rather large information elements it was agreed that new system information blocks (SIB) was needed.

[0150] NR NTN SIB19 contains the required information to access an NTN cell: An example description of SIB19 based on Technical Specification (TS) 38.331 V18.0.0 can be represented as shown in [Table 1] below.

[0151] - SIB19SIB19 contains satellite assistance information for NTN access.SIB19 information element:-- ASN1START-- TAG-SIB19-STARTSIB19-r17 ::= SEQUENCE {ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need Rt-Service-r17 INTEGER (0..549755813887) OPTIONAL, -- Need RreferenceLocation-r17 ReferenceLocation-r17 OPTIONAL, -- Need RdistanceThresh-r17 INTEGER(0..65525) OPTIONAL, -- Need Rntn-NeighCellConfigList-r17 NTN-NeighCellConfigList-r17 OPTIONAL, -- Need RlateNonCriticalExtension OCTET STRING OPTIONAL,...,[[ntn-NeighCellConfigListExt-v1720 NTN-NeighCellConfigList-r17 OPTIONAL -- Need R]],[[movingReferenceLocation-r18 ReferenceLocation-r17 OPTIONAL, -- Need RsatSwitchWithReSync-r18 SatSwitchWithReSync-r18 OPTIONAL -- Need R]]}NTN-NeighCellConfigList-r17 ::= SEQUENCE (SIZE(1..maxCellNTN-r17)) OF NTN-NeighCellConfig-r17NTN-NeighCellConfig-r17 ::= SEQUENCE {ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need RcarrierFreq-r17 ARFCN-ValueNR OPTIONAL, -- Need RphysCellId-r17 PhysCellId OPTIONAL -- Need R}SatSwitchWithReSync-r18 ::= SEQUENCE {ntn-Config-r18 NTN-Config-r17,t-ServiceStart-r18 INTEGER (0..549755813887) OPTIONAL, -- Need Rssb-TimeOffset-r18 INTEGER (0..159) OPTIONAL -- Need R}-- TAG-SIB19-STOP-- ASN1STOP

[0152] SIB19 field descriptions:

[0153] a) distanceThresh: Distance from the serving cell reference location and is used in location-based measurement initiation in an RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. Each step represents 50m. This field is only present in an NTN cell.

[0154] b) movingReferenceLocation: Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. The time reference of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when determining changes in system information, i.e., changes to movingReferenceLocation should neither result in system information change notifications nor in a modification of valueTag in SIB1. This field is only present in an NTN cell.

[0155] c) ntn-Config: Provides parameters needed for the UE (100) to access NR via NTN access such as Ephemeris data, common TA parameters, k_offset, validity duration for UL sync information and epoch. In a TN cell, this field is only present in ntn-NeighCellConfigList and ntn-NeighCellConfigListExt.

[0156] d) ntn-NeighCellConfigList, ntn-NeighCellConfigListExt: Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and PhysCellId. This set includes all elements of ntn-NeighCellConfigList and all elements of ntn-NeighCellConfigListExt. If ntn-Config is absent for an entry in ntn-NeighCellConfigListExt, the ntn-Config provided in the entry at the same position in ntn-NeighCellConfigList applies. The network entity (200) provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn-Config is absent for any other entry in ntn-NeighCellConfigList, the ntn-Config provided in the previous entry in ntn-NeighCellConfigList applies.

[0157] e) referenceLocation: Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in location-based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304. This field is only present in an NTN cell.

[0158] f) satSwitchWithReSync: Provides parameters for the target satellite required to perform satellite switch with re-synchronization. This field is only present in an NTN cell and its presence indicates that satellite switch without PCI change is supported in the cell.

[0159] g) t-Service: Indicates the time information on when a cell provided via NTN system is going to stop serving the area it is currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder link switches for both NTN quasi-Earth fixed and Earth moving system. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this field. The reference point for t-Service is the uplink time synchronization reference point of the cell. This field is only present in an NTN cell.

[0160] In NTNs, there are also certain fields of other SIBs that are different in NTN. For instance, in SIB1, it is possible to signal multiple tracking areas for the single Public Land Mobile Network (PLMN). This can be done to ensure that excessive tracking area updates are not performed by UEs.

[0161] NTN introduced distance based conditional handover using conditional event D1.Event D1 (Distance between UE and referenceLocation1 is above threshold1 and distance between UE and referenceLocation2 is below threshold2)

[0162] The UE shall:

[0163] 1> consider the entering condition for this event to be satisfied when both condition D1-1 and condition D1-2, as specified below, are fulfilled;

[0164] 1> consider the leaving condition for this event to be satisfied when condition D1-3 or condition D1-4, i.e. at least one of the two, as specified below, are fulfilled;

[0165] Inequality D1-1 (Entering condition 1)

[0166]

[0167] Inequality D1-2 (Entering condition 2)

[0168]

[0169] Inequality D1-3 (Leaving condition 1)

[0170]

[0171] Inequality D1-4 (Leaving condition 2)

[0172]

[0173] The variables in the formula are defined as follows:

[0174] Ml1is the distance between UE and a reference location for this event (i.e. referenceLocation1 as defined within reportConfigNR for this event), not taking into account any offsets.

[0175] Ml2is the distance between UE and a reference location for this event (i.e. referenceLocation2 as defined within reportConfigNR for this event), not taking into account any offsets.

[0176] Hysis the hysteresis parameter for this event (i.e. hysteresisLocation as defined within reportConfigNR for this event).

[0177] Thresh1is the threshold for this event defined as a distance, configured with parameter distanceThreshFromReference1, from a reference location configured with parameter referenceLocation1 within reportConfigNR for this event.

[0178] Thresh2is the threshold for this event defined as a distance, configured with parameter distanceThreshFromReference2, from a reference location configured with parameter referenceLocation2 within reportConfigNR for this event.

[0179] Ml1is expressed in meters.

[0180] Ml2is expressed in the same unit asMl1.

[0181] Hysis expressed in the same unit asMl1.

[0182] Thresh1is expressed in the same unit asMl1.

[0183] Thresh2is expressed in the same unit asMl1.

[0184] NOTE: The definition of Event D1 also applies to CondEvent D1.

[0185] Optimising NTN using manual parameter tuning is a complex task and a SON / MDT based system is desirable.

[0186] Further, a Small Data Transmission (SDT) is a procedure allowing data and / or signaling transmission while remaining the UE (100) is in RRC_INACTIVE state (i.e. without transitioning to RRC_CONNECTED state). The SDT is enabled on a radio bearer basis and can be initiated either by the UE (100) in the case of MO-SDT (Mobile Originated SDT) or by the network entity (200) in the case of MT-SDT (Mobile Terminated SDT). The MO-SDT is initiated by the UE (100) only if less than or equal to a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled, a downlink Reference Signal Received Power (DL RSRP) is above a configured threshold, and a valid SDT resource is available. The MT-SDT is initiated by the network with an indication to the UE (100) in a paging message when a DL data awaits transmission for radio bearers configured for the SDT. Based on the indication, the UE (100) initiates the MT-SDT only if the DL RSRP is above a configured threshold. When MT-SDT is initiated by the UE (100), a resume cause indicating the MT-SDT is included in a RRCResumeRequest / RRCResumeRequest1. The maximum duration the SDT procedure can last is dictated by a SDT failure detection timer that is configured by the network entity (200). The network entity (200) can enable MO-SDT, MT-SDT, or both in a cell.

[0187] Optimising SDT using manual parameter tuning is a complex task and a SON / MDT based system is desirable.

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

[0189] In general, a UE may log various events and information and report to the network for supporting optimizations. Some of the information that may be logged are RA-Report, RLF-Report and SHR (Successful Handover Report), SPR (SuccessPSCell-Report).

[0190] Contents of the message as per Release 18 NR specifications can be represented as shown in [Table 2] below.

[0191] RA-ReportList-r16 ::= SEQUENCE (SIZE (1..maxRAReport-r16)) OF RA-Report-r16RA-Report-r16 ::= SEQUENCE {cellId-r16 CHOICE {cellGlobalId-r16 CGI-Info-Logging-r16,pci-arfcn-r16 PCI-ARFCN-NR-r16},ra-InformationCommon-r16 RA-InformationCommon-r16OPTIONAL,raPurpose-r16 ENUMERATED {accessRelated, beamFailureRecovery, reconfigurationWithSync, ulUnSynchronized,schedulingRequestFailure, noPUCCHResourceAvailable, requestForOtherSI,msg3RequestForOtherSI-r17, lbtFailure-r18, spare7, spare6, spare5, spare4, spare3,spare2, spare1},...,[[spCellID-r17 CGI-Info-Logging-r16 OPTIONAL]]}RA-InformationCommon-r16 ::= SEQUENCE {absoluteFrequencyPointA-r16 ARFCN-ValueNR,locationAndBandwidth-r16 INTEGER (0..37949),subcarrierSpacing-r16 SubcarrierSpacing,msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msg1-SubcarrierSpacing-r16 SubcarrierSpacingOPTIONAL,msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacingOPTIONAL,msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL,msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight}OPTIONAL,perRAInfoList-r16 PerRAInfoList-r16,...,[[perRAInfoList-v1660 PerRAInfoList-v1660 OPTIONAL]],[[msg1-SCS-From-prach-ConfigurationIndex-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL]],[[msg1-SCS-From-prach-ConfigurationIndexCFRA-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL]],[[msgA-RO-FrequencyStart-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msgA-RO-FrequencyStartCFRA-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msgA-SubcarrierSpacing-r17 SubcarrierSpacingOPTIONAL,msgA-RO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,msgA-RO-FDMCFRA-r17 ENUMERATED {one, two, four, eight}OPTIONAL,msgA-SCS-From-prach-ConfigurationIndex-r17 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL,msgA-TransMax-r17 ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200}OPTIONAL,msgA-MCS-r17 INTEGER (0..15) OPTIONAL,nrofPRBs-PerMsgA-PO-r17 INTEGER (1..32)OPTIONAL,msgA-PUSCH-TimeDomainAllocation-r17 INTEGER (1..maxNrofUL-Allocations) OPTIONAL,frequencyStartMsgA-PUSCH-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,nrofMsgA-PO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,dlPathlossRSRP-r17 RSRP-Range OPTIONAL,intendedSIBs-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL,ssbsForSI-Acquisition-r17 SEQUENCE (SIZE (1..maxNrofSSBs-r16)) OF SSB-Index OPTIONAL,msgA-PUSCH-PayloadSize-r17 BIT STRING (SIZE (5))OPTIONAL,onDemandSISuccess-r17 ENUMERATED {true}OPTIONAL]],[[usedFeatureCombination-r18 ReportedFeatureCombination-r18OPTIONAL,triggeredFeatureCombination-r18 ReportedFeatureCombination-r18 OPTIONAL,startPreambleForThisPartition-r18 INTEGER (0..63)OPTIONAL,numberOfPreamblesPerSSB-ForThisPartition-r18 INTEGER (1..64)OPTIONAL,attemptedBWP-InfoList-r18 SEQUENCE (SIZE (1..maxNrofBWPs)) OF AttemptedBWP-Info-r18 OPTIONAL,numberOfLBTFailures-r18 INTEGER (1..128)OPTIONAL,perRAInfoList-v1800 PerRAInfoList-v1800 OPTIONAL,sdt-Failed-r18 ENUMERATED {true} OPTIONAL,intendedSIBs-r18 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r18 OPTIONAL]]}}

[0192] One of the main issues with respect to self-optimization is the overhead with respect to the storage and reporting of the information. The UEs need to reserve memory for storing the self-optimization data and from user's perspective this data is an overhead, as it is not related to any of the services. Similarly, there is a signaling overhead on the air interface for reporting this data. There are some impacts on the power consumption during the transfer of this information. Hence it is important to minimize the amount of data stored or reported for SON MDT purposes.

[0193] Conditions for initiating SDT:According to TS 38.331, conditions for initiating SDT are specified as below:

[0194] When requesting lower layers to check the conditions for initiating SDT, an RRC indicates to lower layers whether a resume procedure is initiated for mobile originated or mobile terminated case.

[0195] The UE in an RRC_INACTIVE initiates the resume procedure for the SDT when all of the following conditions are fulfilled:

[0196] 1> for the resume procedure initiated by the upper layers (i.e. mobile originated case):

[0197] 2> SIB1 includes sdt-ConfigCommon; and

[0198] 2> sdt-Config is configured; and

[0199] 2> all the pending data in UL is mapped to the radio bearers configured for SDT; and

[0200] 2> for an (e)RedCap UE when RedCap-specific initial downlink BWP includes no CD-SSB, ncd-SSB-RedCapInitialBWP-SDT is configured; and

[0201] 2> lower layers indicate that conditions for initiating MO-SDT as specified in TS 38.321 are fulfilled.

[0202] 1> for the resume procedure initiated in response to RAN paging (i.e. mobile terminated case):

[0203] 2> lower layers indicate that conditions for initiating MT-SDT as specified in TS 38.321 are fulfilled.

[0204] For the purpose of SON enhancements for SDT, the UE includes RSRP / data volume related information in the reports sent to the network entity. This includes the Downlink RSRP value and buffered uplink data volume at the time when the UE evaluates if it should perform SDT (also referred to as SDT data volume in this invention). The UE may report the data volume of the pending UL data across all RBs configured for SDT.

[0205] When the SDT failure happens, the UE can indicate the failure cause of SDT to the network entity, e.g. T319a expiration. The RSRP and data volume can also be included in such report.

[0206] 3GPP release 18 (V18.2.0) of specifications like TS 38.331, TS38.300 and TS 38.321 are considered as background for the present disclosure.

[0207] Embodiments disclosed herein provides a system and method for reporting SDT information for SON / MDT in NR and other wireless technologies. In the method, the UE reports data volume related information and RSRP information for SDT to the network entity for SON / MDT purposes. The UE reports the SDT data volume to the network entity for SON / MDT purpose in bytes. Reporting the data volume in bytes provide an optimal granularity for the optimization considering that the data is typically Internet Protocol (IP) data and is transmitted and received in bytes. The UE checks when the SDT data volume to be reported for SON / MDT is above a constant, N and when it is above N, the UE reports N. Otherwise, the UE reports the actual data volume. This helps the network entity to perform optimizations without suffering from a very large signaling overhead, and also reduces the memory and processing requirements at the UE. In an embodiment, when M>N, UE doesn't log the SDT data volume in the SON / MDT reports. In an embodiment, the UE reports the SDT data volume to the network entity for SON / MDT purpose only for MO SDT and not for MT SDT. For example, when the random access is initiated due to MT SDT, UE may not report the SDT data volume. This ensures that the data volume information is reported optimally, and also helps the network entity to identify the type of SDT using the presence or absence of the data volume in the report.

[0208] In an embodiment, the value range of SDT-UL-DataVolume is 0 to 96000 bytes. The UE reports 96000 when the data volume is larger than 96000. In an embodiment, the UL data volume is reported only for MO SDT and only radio bearers configured for SDT are considered.

[0209] The embodiments herein achieve methods and systems for performing self-optimization of inter-RAT (Radio Access Technology) mobility between 5G NR (New Radio) and LTE (Long Term Evolution) in wireless networks.

[0210] The embodiments herein achieve methods and systems for enabling the UE and the network for handling the RLF due to expiry of the t-service. Embodiments herein disclose methods and systems for enabling the UE to report tracking area information in the NTN cell in SON / MDT reports. Embodiments herein disclose methods and systems for enabling the UE to provide information (i.e., the network entity receives information) for optimizing conditional handovers in NTN.

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

[0212] FIG. 3 illustrates an overview of a wireless network (300), according to embodiments as disclosed herein. The wireless network (300) includes a UE (100) and a network entity (200). The wireless network (300) can be, for example, but not limited to a fourth generation (4G) network, a fifth generation (5G) network, a sixth generation (6G) network, an Open Radio Access Network (ORAN) or the like. The UE (100) can be, for example, but not limited to a laptop, a smart phone, a desktop computer, a notebook, a Device-to-Device (D2D) device, a vehicle to everything (V2X) device, a foldable phone, a smart TV, a tablet, an immersive device, and an internet of things (IoT) device. The network entity (200) can be, for example, but not limited to a gNB, an eNB, a new radio (NR) trans-receiver or the like.

[0213] In an embodiment, the UE (100) reports the SDT data volume to the network entity (200) for SON / MDT purpose in bytes. In an embodiment, the UE (100) checks if a SDT data volume to be reported for SON / MDT is above a constant, N and if it is above N, the UE (100) reports N. Otherwise, the UE (100) reports an actual data volume. This helps the network entity (200) to perform optimizations without suffering from a very large signaling overhead, and also reduces a memory (114) (as shown in FIG. 4) and processing requirements at the UE (100).

[0214] In an embodiment, constant N is in bytes. For e.g. Let us consider the case where the SDT data volume to be reported is M bytes. Now there are three cases:

[0215] a. M < N: the UE (100) reports M,

[0216] b. M = N: the UE (100) reports N (same as UE reports M, as both are equal), and

[0217] c. M > N: the UE (100) reports N

[0218] In an embodiment N is 96000 bytes. The network entity (200) uses the reported data volume to adjust the configuration of data volume threshold. The maximum configurable value of data volume threshold in NR is 96000 bytes and any data volume above the same may be considered as not suitable for SDT.

[0219] In an embodiment, if M>N, the UE (100) doesn't log the SDT data volume in the SON / MDT reports.

[0220] In an embodiment the UE (100) reports the SDT data volume to the network entity (200) for the SON / MDT purpose as an index M to a set of values, such as sdt-DataVolumeThreshold-r17 ENUMERATED {byte32, byte100, byte200, byte400, byte600, byte800, byte1000, byte2000, byte4000, byte8000, byte9000, byte10000, byte12000, byte24000, byte48000, byte96000}. If actual data volume is less than first entry, the UE (100) reports 1, if it is more than first entry and less than second entry, the UE (100) reports 2, if, if it is more than second entry and less than third entry, the UE (100) reports 3 etc. If it is less than entry N and more than N-1, according to this embodiment, the UE (100) reports N. If it is more than the last entry, x, the UE (100) reports x+1.

[0221] In an embodiment, the UE (100) reports the SDT data volume to the network entity (200) for SON / MDT purpose only for MO SDT and not for MT SDT. For example, if the random access is initiated due to MT SDT, the UE (100) may not report the SDT data volume.

[0222] In an example embodiment, SDT data volume can be represented as shown in [Table 3] below.

[0223] RA-InformationCommon-r16 ::= SEQUENCE {absoluteFrequencyPointA-r16 ARFCN-ValueNR,locationAndBandwidth-r16 INTEGER (0..37949),subcarrierSpacing-r16 SubcarrierSpacing,msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msg1-SubcarrierSpacing-r16 SubcarrierSpacingOPTIONAL,msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacingOPTIONAL,msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL,msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight} OPTIONAL,perRAInfoList-r16 PerRAInfoList-r16,...,[[perRAInfoList-v1660 PerRAInfoList-v1660 OPTIONAL]],[[msg1-SCS-From-prach-ConfigurationIndex-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL]],[[msg1-SCS-From-prach-ConfigurationIndexCFRA-r16 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL]],[[msgA-RO-FrequencyStart-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msgA-RO-FrequencyStartCFRA-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,msgA-SubcarrierSpacing-r17 SubcarrierSpacingOPTIONAL,msgA-RO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,msgA-RO-FDMCFRA-r17 ENUMERATED {one, two, four, eight} OPTIONAL,msgA-SCS-From-prach-ConfigurationIndex-r17 ENUMERATED {kHz1dot25, kHz5, spare2, spare1} OPTIONAL,msgA-TransMax-r17 ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200} OPTIONAL,msgA-MCS-r17 INTEGER (0..15) OPTIONAL,nrofPRBs-PerMsgA-PO-r17 INTEGER (1..32)OPTIONAL,msgA-PUSCH-TimeDomainAllocation-r17 INTEGER (1..maxNrofUL-Allocations) OPTIONAL,frequencyStartMsgA-PUSCH-r17 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL,nrofMsgA-PO-FDM-r17 ENUMERATED {one, two, four, eight} OPTIONAL,dlPathlossRSRP-r17 RSRP-Range OPTIONAL,intendedSIBs-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL,ssbsForSI-Acquisition-r17 SEQUENCE (SIZE (1..maxNrofSSBs-r16)) OF SSB-Index OPTIONAL,msgA-PUSCH-PayloadSize-r17 BIT STRING (SIZE (5))OPTIONAL,onDemandSISuccess-r17 ENUMERATED {true}OPTIONAL]],[[selectedFeatureCombination-r18 FeatureCombination-r17OPTIONAL,triggeredFeatureCombination-r18 FeatureCombination-r17OPTIONAL,attemptedBWPInfo-r18 SEQUENCE (SIZE (1..maxNrofBWPs-1-r18)) OF AttemptedBWPInfo-r18 OPTIONAL,sdtDataVolume-r19 INTEGER (1..N) OPTIONAL]]}

[0224] sdtDataVolume:This field is used to indicate the data volume of a pending UL data across all RBs configured for SDT when the UE (100) evaluates if the UE (100) should perform SDT. If the data volume of the pending UL data across all RBs configured for SDT when the UE (100) evaluates if it should perform SDT exceeds or equals to N, the UE (100) sets the field to N.

[0225] In an embodiment, the SDT data volume is reported in RA-InformationCommon and is included in Radio Link Failure (RLF) report, Random Access (RA) report, Successful Handover Report (SHR), Successful PSCell Change or Addition Information (SPR), Connection Establishment Failure Report (CEF) etc.

[0226] In an embodiment, a DRB (data radio bearer) is considered for SDT data volume reporting if it is part of the sdt-DRB-List-r17 received from the network entity (200). In an embodiment, SRB2 is considered for SDT data volume reporting if sdt-SRB2-Indication-r17 received from the network entity (200) is set as true. This ensures that any data in the bearers other than the ones configured by the network entity (200) for SDT are not considered for SDT data volume reporting, there by not contaminating the reporting of SDT data volume.

[0227] In an embodiment, if there is no available data across all RBs configured for SDT when the UE (100) evaluates if it should perform SDT, the UE (100) reports 0 as sdtDataVolume. Since there may be other bearers with available data, reporting the value 0 helps the network to identify the actual data volume related to SDT.

[0228] In an alternative embodiment, if there is no available data across all RBs configured for SDT when the UE (100) evaluates if it should perform SDT, the UE (100) doesn't include the field sdtDataVolume.

[0229] In an embodiment, the embodiments about reporting SDT data volume when the UE (100) evaluates if it should perform SDT is also applicable for the case where the UE (100) reports SDT data volume when the SDT has failed.

[0230] The UE (100) may evaluate if it should perform SDT and may not perform the SDT after evaluation as the evaluation has failed. The UE (100) may report the SDT data volume using the embodiments in the invention.

[0231] In an embodiment, if there is data in at least one DRB where SDT is not applicable, the UE (100) informs this to the network entity (200). The UE (100) may include the DRBI id in the SON / MDT reports sent to the network entity (200).

[0232] In an embodiment, the UE (100) informs the network entity (200) if it has received RRCSetup while SDT procedure is ongoing.

[0233] In an embodiment, the UE (100) logs and reports to the network entity (200) the action occurred in response to a resume procedure initiated for SDT. The actions may be one of the following:

[0234] a. the network entity (200) resumed the suspended RRC connection and sent the UE (100) to the RRC_CONNECTED,

[0235] b. the network entity (200) rejected the request to resume and send the UE (100) to RRC_INACTIVE with a wait timer,

[0236] c. the network entity (200) re-suspended the RRC connection and sent the UE (100) to the RRC_INACTIVE,

[0237] d. the network entity (200) released the RRC connection and sent the UE (100) to the RRC_IDLE, and

[0238] e. the network entity (200) instructed the UE (100) to initiate Non-Access Stratum (NAS) level recovery.

[0239] In an embodiment, the UE (100) logs and reports the data volume for SDT reporting at the time when the UE (100) evaluates if it should perform SDT in the RA report and other SON / MDT reports, if the UE RRC has requested lower layers (e.g., UE MAC) for checking the conditions for initiating SDT, and UE RRC has informed UE MAC that SDT is MO-SDT.

[0240] In an embodiment, the UE (100) includes a Downlink RSRP value at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports if the UE RRC has requested lower layers (UE MAC) for checking the conditions for initiating SDT, for MO-SDT and / or MT-SDT.

[0241] In an embodiment, the UE (100) logs and reports the data volume for SDT reporting at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports, when the following conditions are met:

[0242] a. SIB1 includes sdt-ConfigCommon,

[0243] b. sdt-Config is configured,

[0244] c. all the pending data in UL is mapped to the radio bearers configured for SDT,

[0245] d. for an (e)RedCap UE when RedCap-specific initial downlink BWP includes no CD-SSB, ncd-SSB-RedCapInitialBWP-SDT is configured, and

[0246] e. Resume procedure is mobile originated.

[0247] In an embodiment, for MO SDT, the UE (100) logs and reports the DL RSRP value at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports, when the following conditions are met:

[0248] a. SIB1 includes sdt-ConfigCommon,

[0249] b. sdt-Config is configured,

[0250] c. all the pending data in UL is mapped to the radio bearers configured for SDT, and

[0251] d. for an (e)RedCap UE when RedCap-specific initial downlink BWP includes no CD-SSB, ncd-SSB-RedCapInitialBWP-SDT is configured.

[0252] In an embodiment, the UE (100) logs and reports the data volume for the SDT reporting at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports, if the resume procedure for SDT is initialized and the resume procedure is mobile originated.

[0253] In an embodiment, the UE (100) includes the Downlink RSRP value at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports, if the resume procedure for SDT is initialized for MT SDT.

[0254] In an embodiment, the UE (100) logs and reports the data volume for SDT reporting at the time when the UE (100) evaluates if it should perform SDT in RA report and other SON / MDT reports, when the following conditions are met:

[0255] a. SIB1 includes sdt-ConfigCommon

[0256] b. sdt-Config is configured

[0257] c. all the pending data in UL is mapped to the radio bearers configured for SDT

[0258] d. for an (e)RedCap UE when RedCap-specific initial downlink BWP includes no CD-SSB, ncd-SSB-RedCapInitialBWP-SDT is configured.

[0259] e. Resume procedure is mobile originated.

[0260] f. The UE MAC indicates that conditions for initiating MO-SDT are fulfilled.

[0261] In an embodiment, the UE (100) informs the network entity (200) whether the radio link failure is because to a cell provided via an NTN system has stopped serving the area it is currently covering. The UE (100) may provide the information using a specific RLF cause or may include a flag in the RLF report to convey this information. The information will help network entity (200) to identify the RLF due to satellite stopping service from other RLFs, and network entity (200) may have different optimization strategy such as different techniques for updating the handover related parameters.

[0262] In an embodiment, if the serving cell has provided t-Service and the UE (100) loses service (such as the UE (100) has experienced RLF) at t-Service, the UE informs the network entity (200) that the RLF happened at t-Service expiry. The UE (100) may provide this information using a specific RLF cause or may include a flag in the RLF report to convey this information.

[0263] In an embodiment, the UE (100) logs and reports whether t-Service was signaled by the cell where the radio link failure has occurred or has not occurred, and the UE (100) will report this regardless of whether the t-Service expired or not in the SON / MDT reports. In an embodiment, this may be included in RLF report, SHR, SPR, etc.

[0264] In an embodiment, the UE (100) reports that t-Service was about to expire, i.e., that t-Service for instance was within a certain time of expiring. For instance, if the t-Service was within 1 second of expiring. This can be configurable, i.e., a flag or a number (integer) that indicates that t-Service was within a configurable limit of expiring. In an embodiment, this may be included in RLF report, SHR, SPR, etc.

[0265] In an embodiment, the UE (100) provides information to identify the radio link failures due to satellite stopping service from other radio link failure causes.

[0266] In an embodiment, the UE (100) informs the network entity (200) whether it has performed soft satellite switch with resynchronization. In an alternate embodiment, if the radio link failure is due to cell provided via the NTN system has stopped serving the area it is currently covering, the UE (100) skips logging the radio link failure report for that radio link failure.

[0267] In an embodiment, the UE (100) may include the t-service value, and the t-service value has received in the RLF report. In an embodiment, the UE (100) may include the t-service value in SON / MDT reports such as successful handover report (SHR) or Successful PSCell Report (SPR) etc.

[0268] In an embodiment, the UE (100) logs the tracking area list in the SON / MDT reports. When the SON / MDT reports are retrieved by a gNB which is different from the gNB associated with the report, the gNB that performs retrieval uses the tracking area list to forward the received reports to the gNBs associated to the SON / MDT report. The gNB that performs retrieval may forward to multiple gNBs based on the tracking area list.

[0269] In an embodiment, the UE (100) logs the tracking area list received in the system information messages such as SIB1 in the SON / MDT reports.

[0270] In NR, if the UE (100) is logging CGI-Info-Logging in the SON / MDT reports and the UE (100) has received a list of tracking areas such as trackingarealist, the UE (100) logs the trackingarealist in the CGI-Info-Logging. In an example embodiment, CGI-Info-Logging can be represented as shown in [Table 4] below.

[0271] -- TAG-CGI-INFO-LOGGING-STARTCGI-Info-Logging-r16 ::= SEQUENCE {plmn-Identity-r16 PLMN-Identity,cellIdentity-r16 CellIdentity,trackingAreaCode-r16 TrackingAreaCode OPTIONAL,trackingAreaList-r18 SEQUENCE (SIZE (1..maxTAC-r17)) OF TrackingAreaCode OPTIONAL}

[0272] In an embodiment, the tracking area list may be included using one of the options in [Table 5] below:

[0273] Option 1:CGI-Info-Logging-v1900 ::= SEQUENCE {plmn-Identity-r19 PLMN-Identity,cellIdentity-r19 CellIdentity,trackingAreaList-r19 SEQUENCE (SIZE (1..maxTAC-r17)) OF TrackingAreaCode OPTIONAL,}Option 2:CGI-Info-Logging-v1900 ::= SEQUENCE {trackingAreaList-r19 SEQUENCE (SIZE (1..maxTAC-r17)) OF TrackingAreaCode OPTIONAL,}-- TAG-CGI-INFO-LOGGING-STOP-- ASN1STOP

[0274] CGI-Info-Logging field descriptions are following:

[0275] a) cellIdentity: Unambiguously identify a cell within the context of the PLMN. It belongs to the first PLMN-IdentityInfo IE of PLMN-IdentityInfoList in SIB1.

[0276] b) plmn-Identity: Identifies the PLMN of the cell for the reported cellIdentity: the first PLMN entry of plmn-IdentityList (in SIB1) in the instance of PLMN-IdentityInfoList that contained the reported cellIdentity.

[0277] c) trackingAreaCode: Indicates Tracking Area Code to which the cell indicated by cellIdentity field belongs.

[0278] d) trackingAreaList: List of Tracking Areas to which the cell indicated by cellIdentity field belongs.

[0279] The inclusion of the tracking area list signaled in the SIB1 for NTN-purposes may be included as a new CGI-Info-Logging field which includes plmn-Identity, cellIdentity and trackingAreaList, or it may only include the trackingAreaList.

[0280] The UE (100) includes the tracking area list in the connection establishment failure report (such as ConnEstFailReport-r16 in NR), radio link failure report (RLF report), and random access report (RA report).

[0281] In an embodiment, the UE (100) may include the tracking area list belonging to the failed cell in the connection establishment failure report.

[0282] In an embodiment, the UE (100) may include the tracking area list belonging to the cell where the logged random access is performed in the RA report. In an embodiment, the UE (100) may include the tracking area list belonging to the SpCell (such as spCellID-r17 in NR) in the RA report.

[0283] In an embodiment, the UE (100) may include the tracking area list belonging to the failed PCell (such as failedPCellId-r16 in NR) in the RLF report. In an embodiment, the UE (100) may include the tracking area list belonging to the previous PCell id such asnrPreviousCellinpreviousPCellId in NR(where the lastRRCReconfigurationmessage includingreconfigurationWithSyncwas received or the lastMobilityFromNRCommandmessage was received or the last executedRRCReconfigurationmessage includingreconfigurationWithSyncwas received) in the RLF report.

[0284] In an embodiment, the UE (100) may include the tracking area list belonging to the cell in which the UE (100) comes back to connected after connection failure and after failing to perform reestablishment, or the suitable cell in which the UE (100) reconnects after failure in performingMobilityFromNRCommandfor voice fallback (without initiating re-establishment procedure) in the RLF report. In an embodiment, the UE (100) may include the tracking area list belonging to the NR reconnectCellId in RLF report.

[0285] In an embodiment, the UE (100) may include the tracking area list belonging to the NR reestablishmentCellId in RLF report. In an embodiment, if the UE (100) was not configured withconditionalReconfigurationat the time of re-establishment attempt, or if the cell selected for the re-establishment attempt is not a candidate target cell for conditional reconfiguration, the UE (100) includes the tracking area list belonging to the cell in which the re-establishment attempt was made after connection failure.

[0286] In an embodiment, the UE (100) may include the tracking area list belonging to the candidate target cell for conditional handover that the UE (100) selected for CHO based recovery or LTM based recovery, while T311 is running. In an embodiment, the UE (100) may include the tracking area list belonging to NRchoCellId.

[0287] In an embodiment, the UE (100) may include the tracking area list belonging to the PSCell in which the UE (100) failed to perform fast MCG recovery procedure or the UE (100) successfully performed fast MCG recovery procedure.

[0288] In an embodiment, the UE (100) may include the tracking area list belonging to a source PCell and a target PCell in successful handover report (SHR).

[0289] In an embodiment, the UE (100) may include the tracking area list belonging to the PCell, the source PSCell and the target PSCell in successful PSCell Addition or Change report (SPR such as SuccessPSCell-Report-r18 in NR).

[0290] In an embodiment, the UE (100) may include the tracking area list belonging to the cells in ChoCandidateCellList in RLF report or SHR.

[0291] In an embodiment, the UE (100) may include the list of tracking areas belonging to the cells in the logged measurement information.

[0292] The tracking area list received from the UE (100) helps the network entity (200) to send the received report to the appropriate network node.

[0293] In an alternative embodiment to providing the tracking area list used in NTN, the UE (100) only includes a single tracking area code out of the tracking areas signaled in SIB1 in the SON / MDT reports. The UE (100) selects one of the tracking areas signaled in SIB1, and signals this in the legacy trackingArea in CGI-Info-Logging. The selection of a single tracking area code may be done by UE (100) randomly selecting one tracking area, or selecting the tracking area the UE (100) is currently associated with or has selected, or selecting the most suitable tracking area. Which tracking area that the UE (100) selects may be considered "up to UE implementation" The UE (100) may consider one or more of the following for identifying the tracking area code to be included in the SON / MDT reports: registration area, forbidden tracking areas, service area restrictions, local area data network (LADN) information, UE's location information and information of geographical area of Tracking Areas and satellite trajectory. In an embodiment, the tracking area included in CGI-Info-Logging is the tracking area selected by UE NAS from the multiple tracking area codes broadcasted by the system information in the cell. Including a single tracking area avoids the complexity of reporting the entire tracking area list at both the UE (100) and the network entity (200).

[0294] In an embodiment, the UE (100) may log and report whether the conditional event D1 (or the event where the distance between the UE (100) and a reference location such asreferenceLocation1becomes larger than a configured threshold such asdistanceThreshFromReference1and distance between the UE (100) and a reference locationreferenceLocation2of conditional reconfiguration candidate becomes shorter than a configured threshold such asdistanceThreshFromReference2)was satisfied in SON / MDT reports such as RLF report, SHR, SPR etc.

[0295] In an embodiment, the UE (100) may log and report the distance between the UE (100) and a reference location such asreferenceLocation1where in thereferenceLocation1 is configuredfor reportingevents such as NREvent D1 (or similar events in other technologies) or for evaluating conditionalevents such as NR CondEvent D1 (or similar events in other technologies). In an embodiment, the UE (100) may log and report the distance between the UE (100) and a reference location such asreferenceLocation2where in thereferenceLocation2 is configuredfor reportingevents such as NREvent D1 (or similar events in other technologies) or for evaluating conditionalevents such as NR CondEvent D1 (or similar events in other technologies). In an embodiment logging of the distance between the UE (100) and referenceLocation1 or between the UE and referenceLocation2 is done in SON / MDT reports such as RLF report, SHR, SPR etc. As described in the stated background specification TS 38.331, referenceLocation1is associated to serving cell andreferenceLocation2is associated to candidate target cell.

[0296] Reporting the distance information helps the network entity (100) to optimize the conditional handover. The network entity (200) may adjust the referenceLocation1 or referenceLocation2 based on the received information.

[0297] In an embodiment, the UE (100) reports whether the conditional event D2 (or the event where the distance between the UE (100) and a moving reference location determined based on movingReferenceLocation and its corresponding satellite ephemeris and epoch time for e.g. broadcast in SIB19 for the serving cell becomes larger than configured threshold such as distanceThreshFromReference1 and distance between the UE (100) and the moving reference location determined based on referenceLocation2 of conditional reconfiguration candidate becomes shorter than a configured threshold such as distanceThreshFromReference2) was satisfied in SON / MDT reports such as RLF report, SHR, SPR etc. In an embodiment, the UE (100) may log and report the distance between the UE (100) and the reference location such asreferenceLocation1where in thereferenceLocation1 is configuredfor reportingevents such as NREvent D2 (or similar events in other technologies) or for evaluating conditionalevents such as NR CondEvent D2 (or similar events in other technologies). In an embodiment, the UE (100) may log and report the distance between the UE (100) and a reference location such asreferenceLocation2where in thereferenceLocation2 is configuredfor reportingevents such as NREvent D2 (or similar events in other technologies) or for evaluating conditionalevents such as NR CondEvent D2 (or similar events in other technologies). In an embodiment logging of the distance between the UE (100) and the referenceLocation1 or between the UE (100) and referenceLocation2 is done in SON / MDT reports such as RLF report, SHR, SPR etc.

[0298] In an embodiment, the UE (100) may log and report whether the conditional event T1 (such as NR event fulfilled when time measured at UE (100) becomes more than configured threshold t1-Threshold but is less than t1-Threshold + duration) is satisfied in SON / MDT reports such as RLF, SHR, SPR etc. In an embodiment, the UE (100) logs the time difference between the fulfilment of this conditional event T1 and the time of reporting SON / MDT reports such as RLF report, SHR, SPR etc. within RLF report, SHR,SPR etc. In an embodiment, the UE (100) logs the time difference between the configuration of this conditional event T1 and the fulfilment of this conditional event T1 in the SON / MDT reports such as RLF report, SHR, SPR etc.

[0299] The above embodiments may apply to a 5G NR or 4G LTE / E-UTRAN system or 6G system. Similarly, it can be done in a NR NTN system, or an IoT NTN system, which can be either LTE-M (sometimes known only as E-UTRAN or as eMTC) E-UTRAN or NB-IoT system. It may apply if the UE (100) has been connected to an NTN system while the failure occurred, or it may apply if the UE (100) is currently connected to an NTN system.

[0300] The above embodiments may also for instance be included if the system is of a specific NTN system type that is being operated, specifically for instance whether the system is an earth-fixed cell or earth-moving cell system. It may also be indicated in the above cases which type the NTN system is of. The difference between the two systems is whether the cells or the beams that are generated by the satellite towards the ground are fixed on the ground as a satellite moves, or whether they sweep along the ground. Certainness of the information above may for instance be reported in one system or the other.

[0301] FIG. 4 shows various hardware components of the UE (100), according to the embodiments as disclosed herein. In an embodiment, the UE (100) includes a processor (110), a communicator (112), a memory (114), and a SDT data volume handling controller (116). The processor (110) is coupled with the communicator (112), the memory (114), and the SDT data volume handling controller (116).

[0302] The SDT data volume handling controller (116) evaluates whether the SDT can be performed. Further, the SDT data volume handling controller (116) determines that the SDT is the MO SDT. Further, the SDT data volume handling controller (116) determines whether the SDT data volume to be reported is above the predefined value based on the determination. In an embodiment, the predefined value is 96000 bytes.

[0303] In an embodiment, the SDT data volume handling controller (116) reports the actual SDT data volume to the network entity (200) upon determining that the SDT data volume to be reported is not above the predefined value. In another embodiment, the SDT data volume handling controller (116) reports the predefined SDT data volume to the network entity (200) upon determining that the SDT data volume to be reported is above or equal to the predefined value. In an embodiment, the UE (100) reports the SDT data volume to the network entity (116) for the SON purpose and the MDT purpose for the MO SDT.

[0304] In an embodiment, the UE (100) reports zero as SDT data volume, upon determining there is no available data across all RBs configured for the SDT when the UE (100) evaluates that the UE (100) performs the SDT.

[0305] In an embodiment, the SDT data volume is reported when the SDT has failed. In an embodiment, the SDT data volume is reported in a Random Access (RA) report.

[0306] In an embodiment, the UE (100) does not report the SDT data volume when a random access is initiated due to a mobile terminated (MT) SDT.

[0307] In an embodiment, the SDT data volume field indicates a buffered data volume in the UE (100) for a radio bearer configured for the SDT during evaluation of SDT procedure. In an embodiment, the DRB is considered for the SDT data volume reporting when the DRB is part of a sdt-DRB-List-r17 received from the network entity (200). In an embodiment, the SRB2 is considered for the SDT data volume reporting when a sdt-SRB2-Indication-r17 is set as true.

[0308] The SDT data volume handling controller (116) is 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 may optionally be driven by firmware.

[0309] The processor (110) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as 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 (110) may include multiple cores and is configured to execute the instructions stored in the memory (114).

[0310] Further, the processor (110) is configured to execute instructions stored in the memory (114) and to perform various processes. The communicator(112) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (114) also stores instructions to be executed by the processor (110). The memory (114) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (114) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (114) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0311] Although FIG. 4 shows various hardware components of the UE (100) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the UE (100) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purposes and does not limit the scope of the invention. One or more components can be combined together to perform the same or substantially similar function in the UE (100).

[0312] FIG. 5 shows various hardware components of the network entity (200), according to the embodiments as disclosed herein. The network entity (200) includes a processor (210), a communicator (212), a memory (214), and a SDT data volume handling controller (216). The processor (210) is coupled with the communicator (212), the memory (214), and the SDT data volume handling controller (216).

[0313] The SDT data volume handling controller (216) receives one of: reports of the actual SDT data volume from the UE (100) upon determining that the SDT data volume to be reported is not above a predefined value at the UE (100), and reports the predefined SDT data volume from the UE (100) upon determining that the SDT data volume to be reported is above or equal to the predefined value at the UE (100). Further, the SDT data volume handling controller SDT data volume handling controller (216) handles at least one of: the SON purpose and the MDT purpose for the MO SDT based on one of: the actual SDT data volume and the predefined SDT data volume.

[0314] The SDT data volume handling controller (216) is 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 may optionally be driven by firmware.

[0315] The processor (210) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as 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 (210) may include multiple cores and is configured to execute the instructions stored in the memory (214).

[0316] Further, the processor (210) is configured to execute instructions stored in the memory (214) and to perform various processes. The communicator(212) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (214) also stores instructions to be executed by the processor (210). The memory (214) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (214) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (214) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0317] Although FIG. 5 shows various hardware components of the network entity (200) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the network entity (200) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purposes and does not limit the scope of the invention. One or more components can be combined together to perform the same or substantially similar function in the network entity (200).

[0318] FIG. 6 is a flow chart (600) illustrating a method, implemented by the UE (100), for handling a data transmission information in the wireless network (300), according to the embodiments as disclosed herein. The operations (602-610) are handled by the SDT data volume handling controller (116).

[0319] At 602, the method includes evaluating the SDT can be performed. At 604, the method includes determining whether the SDT is the MO SDT. At 606, the method includes determining whether the SDT data volume to be reported is above the predefined value based on the determination.

[0320] In an embodiment, at 608, the method includes reporting the actual SDT data volume to the network entity (200) upon determining that the SDT data volume to be reported is not above the predefined value. In an embodiment, at 610, the method includes reporting the predefined SDT data volume to the network entity (210) upon determining that the SDT data volume to be reported is above or equal to the predefined value.

[0321] Based on the proposed method, Reporting the data volume in bytes provide an optimal granularity for the optimization considering that the data is typically Internet Protocol (IP) data and is transmitted and received in bytes. This helps the network entity (200) to perform optimizations without suffering from a very large signaling overhead, and also reduces the memory and processing requirements at the UE (100). For example, when the random access is initiated due to MT SDT, the UE (100) may not report the SDT data volume. This ensures that the data volume information is reported optimally, and also helps the network entity (200) to identify the type of SDT using the presence or absence of the data volume in the report.

[0322] FIG. 7 is a flow chart (700) illustrating a method, implemented by the network entity (200), for handling the data transmission information in the wireless network (300), according to the embodiments as disclosed herein. The operations (702-706) are handled by the SDT data volume handling controller (216).

[0323] At 702, the method includes receiving a report of the actual SDT data volume from the UE (100) upon determining that the SDT data volume to be reported is not above the predefined value at the UE (100). At 704, the method includes receiving a report of a predefined SDT data volume from the UE upon determining that the SDT data volume to be reported is above or equal to the predefined value at the UE (100). At S706, the method includes handling the SON purpose and the MDT purpose for the MO SDT based on one of: the actual SDT data volume and the predefined SDT data volume.

[0324] FIG. 8 is a flowchart (800) depicting the method for determining and reporting the volume of SDT information data, wherein the SDT is the MO type SDT, according to embodiments as disclosed herein.

[0325] At step 802, the UE (100) evaluates whether the MO SDT should be performed. In an embodiment, the MO SDT is performed when the UE (100) evaluates that, less than or equal to the configured amount of UL data awaits transmission across all radio bearers for which MO SDT is enabled, the downlink Reference Signal Received Power (DL RSRP) is above a configured threshold, and a valid MO SDT resource is available. In an embodiment, the UE (100) can pre-define the range of SDT data volume which can be reported to the network entity (200) for the SON and MDT purpose. In an embodiment, the UE (100) can pre-define the value N which corresponds to a maximum volume of SDT Information data that can be reported to the network entity (200).

[0326] At step 804, the UE (100) checks if the volume of the SDT information data (referred as SDT data volume) to be reported to the network entity (200) with regard to the MO SDT to be performed within the network entity (200), is less than the predefined value N.

[0327] At step 806, the UE (100) stores the SDT data volume as N and report N as SDT data volume to the network entity (200), when SDT data volume to be reported to the network entity (200) is not less than the predefined value N. At step 808, the UE (100) stores and reports actual data volume as SDT data volume to the network entity (200), when SDT data volume to be reported to the network entity (200) is less than the predefined value N.

[0328] FIG. 9 is a sequence diagram (900) that illustrates a method of reporting the SDT data volume to the network entity (200), according to embodiments as disclosed herein.

[0329] At step 1, the network entity (200) transmits a request to report for UE information, wherein the report for UE information can be at least one of an RA report, an RLF report, a CEF report, an SHR and an SPR. At step 2, the UE (100) includes SON report containing SDT data volume, to the report comprising UE information, transmitted to the network entity (200). In an embodiment, the UE (100) reports the SDT data volume to the network entity (200) for SON or MDT purpose in bytes. At step 3, the UE (100) transmits a response, including the SON report comprising UE information on SDT data volume to the network entity (200).

[0330] FIG. 10 depicts a method (1000) for logging t-Service information in SON or MDT reports at the UE (100), according to embodiments as disclosed herein.

[0331] At step 1002, the method includes receiving the t-service from the network entity (200). At step 1004, the method includes generating the SON or MDT report, wherein the report comprising an SHR, an SPR, and an RLF report. At step 1006, the method includes logging t-Service related information in the RLF report.

[0332] FIG. 11 depicts the method (1100) for a method for logging t-Service information in SON or MDT reports at the UE (100), when t-service expiry event occurs, according to embodiments as disclosed herein.

[0333] At step 1102, the method includes receiving the t-service form the network entity (200). At step 1104, the method includes experiencing expiry of the t-service. At step 1106, the method includes logging the t-service related information in the RLF report for reporting to the network entity (200), in order to enable the UE (100) and the network entity (200) to handle RLF due to expiry of the t-service.

[0334] FIG. 12 depicts the method (1200) for logging by the UE (100) tracking area information for an NTN cell in SON or MDT reports, according to embodiments as disclosed herein.

[0335] At step 1202, the method includes receiving the system information including multiple tracking area codes for the NTN cell from the network entity (200). At step 1204, the method includes triggering the UE (100) for logging at least one of an RLF report, a CEF report, an RA report, an SHR, an SPR, and a plurality of Logged measurements. At step 1206, the method includes, including TAC list in the at least one of the RLF report, the CEF report, the RA report, the SHR, the SPR, and the logged measurements, in order to report the TAC list to the network entity (200).

[0336] FIG. 13 depicts the sequence diagram for the method 4000S for performing SON or MDT reporting with conditional event configuration for NTN, according to embodiments as disclosed herein.

[0337] At step 1a, at least one of: the RLF Report of the NTN, the handover failure report of the NTN, the Successful Handover report of the NTN and the Successful PSCell Addition Report of an NTN may be sent by the UE (100), over Xn to the gNB (200a) (referred as source gNB). At step 1b, the UE (100) performs logging information on at least one of a conditional event D1 and a conditional event D2 in an at least one of an RLF report, an SHR, and an SPR. At step 2, the UE (100) transmits an RRC complete message to the gNB (200a), where the reports of the NTN can be available to share with the network entity (200) after completion of the RRC procedure.

[0338] At step 3, the gNB (200a) transmits a request for the information on conditional event configuration for NTN, to the UE (100). At step 4, the UE provides the gNB (200a), the requested NTN related information.

[0339] The various actions, acts, blocks, steps, or the like in the method may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

[0340] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The elements include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0341] Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile deviceor any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g., hardware means like e.g., an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g., using a plurality of CPUs.

[0342] 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 should and 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 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:receiving, from a base station, a UE information request message;setting a random access report list in a UE information response message; andtransmitting, to the base station, the UE information response message,wherein the random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.2.The method of claim 1, wherein:the field indicates a predetermined threshold in case that the data volume is greater than or equal to the predetermined threshold, andthe field indicates the data volume in case that the data volume is less than the predetermined threshold.3.The method of claim 2, wherein the predetermined threshold is 96000 bytes.4.The method of claim 1, wherein the data volume is buffered for at least one radio bearer configured for SDT.5.A method performed by a base station in a wireless communication system, the method comprising:transmitting, to a user equipment (UE), a UE information request message; andreceiving, from the UE, a UE information response message including a random access report list,wherein the random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.6.The method of claim 5, wherein:the field indicates a predetermined threshold in case that the data volume is greater than or equal to the predetermined threshold, andthe field indicates the data volume in case that the data volume is less than the predetermined threshold.7.The method of claim 6, wherein the predetermined threshold is 96000 bytes.8.The method of claim 5, wherein the data volume is buffered for at least one radio bearer configured for SDT.9.A user equipment (UE) comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the UE to:receive, from a base station, a UE information request message,set a random access report list in a UE information response message, andtransmit, to the base station, the UE information response message,wherein the random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.10.The UE of claim 9, wherein:the field indicates a predetermined threshold in case that the data volume is greater than or equal to the predetermined threshold, andthe field indicates the data volume in case that the data volume is less than the predetermined threshold.11.The UE of claim 10, wherein the predetermined threshold is 96000 bytes.12.The UE of claim 9, wherein the data volume is buffered for at least one radio bearer configured for SDT.13.A base station comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the base station to:transmit, to a user equipment (UE), a UE information request message, andreceive, from the UE, a UE information response message including a random access report list,wherein the random access report list includes a field associated with a data volume buffered in the UE during evaluation of a small data transmission (SDT) procedure.14.The base station of claim 13, wherein:the field indicates a predetermined threshold in case that the data volume is greater than or equal to the predetermined threshold,the field indicates the data volume in case that the data volume is less than the predetermined threshold, andthe predetermined threshold is 96000 bytes.15.The base station of claim 13, wherein the data volume is buffered for at least one radio bearer configured for SDT.

Images