Method and apparatus for determining and reporting random access information for self organizing networks in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present invention relates to managing random access information in a wireless network. The method includes triggering a random access procedure by a User Equipment (UE) (101). It further involves logging information about features related to random access procedure, which includes eRedCap, system information and positioning system information. The method also includes transmitting the information related to features related to random access procedure to a network apparatus (201) via an RRC signaling message. Additionally, the method involves optimizing the random access parameters by the network apparatus (201) based on the information received from the UE (101).

Description

METHOD AND APPARATUS FOR DETERMINING AND REPORTING RANDOM ACCESS INFORMATION FOR SELF ORGANIZING NETWORKS IN A WIRELESS COMMUNICATION SYSTEM

[0001] This application is based on and derives the benefit of Indian Provisional Application 202441003294 filed on 17thJanuary 2024, the contents of which are incorporated herein by reference. The proposed embodiments relate to a satellite communication. More particularly, the present disclosure relates to determining and reporting random access information for self-optimization network.

[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 (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[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] The principal object of the embodiments herein is to determine and report random access information in SON. Another object of the invention is to manage random access information in a wireless network.

[0009] Yet another object of the invention is to report random access triggered using a feature combination related to enhanced Reduced Capabilities (eRedCap) or by using eRedCap-related random access resources.

[0010] Yet another object of the invention is to request intended SIBs in the first information element or second information element.

[0011] Yet another object of the invention is to inform the network that OSI is transmitted for requesting positioning system information by using a specific value in the enumeration of SIB-Type-r17.

[0012] In an aspect, the objectives are achieved by providing a method for managing random access information in a wireless network. The method includes triggering by the UE a random access procedure. Further, the method includes logging by the UE an information about features related to random access procedure. The features related to the random access procedure include eRedCap, system information and positioning-related system information. Further, the method includes transmitting by the UE an RRC signaling message to a network apparatus including the information about the features related to related to the random access procedure.

[0013] In another aspect, the objectives are achieved by providing a method for managing random access information in a wireless network. The method includes receiving by a network apparatus an RRC signaling message from a UE indicating information about features related to random access. The features related to the random access include enhancedRedCap (eRedCap), system information and positioning-related system information. Further, the method includes optimizing by the network apparatus, random access parameters based on the received features.

[0014] In yet another aspect, the objectives are achieved by providing a UE for managing random access information in a wireless network. The UE includes a processor and a random access reporting controller communicatively coupled with the processor. Further, the random access reporting controller triggers a random access procedure. Further, the random access reporting controller logs information about the features related to the random access procedure. The features related to the random access procedure include enhancedRedCap (eRedCap), system information and positioning-related system information. Further, the random access reporting controller transmits an RRC signaling message to a network apparatus including the information about the features related to related to the random access procedure.

[0015] In yet another aspect, the objectives are achieved by providing a network apparatus for managing random access information in a wireless network. The network apparatus includes a processor and a random access reporting controller communicatively coupled with the processor. The random access reporting controller receives an RRC signaling message from a UE indicating information about features related to random access. The features related to the random access include eRedCap, system information and positioning-related system information. Further, the random access reporting controller optimizes random access parameters based on the received information about the features.

[0016] 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 preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications can be made within the scope of the embodiments herein.

[0017] Aspects of the present disclosure provide efficient communication methods in a wireless communication system.

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

[0019] FIGURE 1 illustrates a block diagram of a UE for managing random access information in a wireless network according to embodiments disclosed herein.

[0020] FIGURE 2 illustrates a block diagram of a network apparatus for managing random access information in a wireless network according to embodiments disclosed herein.

[0021] FIGURE 3 illustrates a flow diagram that illustrates a method for managing random access information in a wireless network by UE according to embodiments disclosed herein.

[0022] FIGURE 4 illustrates a flow diagram that illustrates a method for managing random access information in a wireless network by network apparatus according to embodiments disclosed herein.

[0023] FIGURE 5 illustrates a flow diagram that illustrates a method for logging and reporting UsedFeatureCombination according to the embodiments as disclosed herein.

[0024] FIGURE 6 illustrates a flow diagram that illustrates a method for logging and reporting triggeredFeatureCombination according to the embodiments as disclosed herein.

[0025] FIGURE 7 illustrates a sequence diagram that illustrates reporting information for eRedCap, system information and positioning system information to gNB according to the embodiments as disclosed herein.

[0026] FIGURE 8 illustrates a flow diagram that illustrates a method for logging the information related to the intended system information in RA-InformationCommon according to the embodiments as disclosed herein.

[0027] FIGURE 9 illustrates a sequence diagram that illustrates reporting intendedSIBs to gNB according to the embodiments as disclosed herein.

[0028] FIGURE 10A illustrates a flow diagram that illustrates a method for handling MHI when the UE deregisters and registers on the same network according to the embodiments as disclosed herein.

[0029] FIGURE 10B illustrates a flow diagram that illustrates a method for handling MHI when the UE deregisters and registers on a different network according to the embodiments as disclosed herein.

[0030] FIGURE 11 illustrates a block diagram illustrating a structure of a UE according to the embodiments as disclosed herein.

[0031] FIGURE 12 illustrates a block diagram illustrating a structure of a base station according to the embodiments as disclosed herein.

[0032] It may be noted that, to the extent possible, like reference numerals have been used to represent like elements in the drawing. Furthermore, those of ordinary skill in the art will appreciate that elements in the drawing are illustrated for simplicity and may not necessarily have been drawn to scale. For example, the dimensions of some of the elements in the drawing may be exaggerated relative to other elements to improve the understanding of aspects of the invention. Further, 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 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 the benefit of the description herein.

[0033] It may be noted that, to the extent possible, like reference numerals have been used to represent like elements in the drawing. Furthermore, those of ordinary skill in the art will appreciate that elements in the drawing are illustrated for simplicity and may not necessarily have been drawn to scale. For example, the dimensions of some of the elements in the drawing may be exaggerated relative to other elements to improve the understanding of aspects of the invention. Further, 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 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 the benefit of the description herein.

[0034] As is traditional in the field, embodiments are described and illustrated in terms of blocks that carry out a described function or functions. These blocks, which are 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 firmware and software. The circuits, for example, may 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 proposed method. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the proposed method.

[0035] The accompanying drawings are used to help easily understand various technical features, and it is understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the proposed method is construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms "first," "second," etc. are used herein to describe various elements, these elements are not limited by these terms. These terms are generally used to distinguish one element from another.

[0036] The evolution of wireless communication systems has led to the development of the 5G network, which aims to provide enhanced connectivity, higher data rates, and improved reliability. A critical component of the 5G architecture is the random access (RA) procedure, which facilitates uplink (UL) time synchronization and supports various operations such as initial access, handover, radio resource control (RRC) connection re-establishment, scheduling request transmission, secondary cell group (SCG) addition / modification, beam failure recovery, and data or control information transmission by non-synchronized user equipment (UE) in the RRC_CONNECTED state. Despite its significance, the RA procedure presents several challenges that can impact the overall performance and efficiency of 5G networks.

[0037] In the Contention-Based Random Access (CBRA), the UE first transmits a Random Access preamble (also referred to as Msg1) and then waits for a Random Access Response (RAR) in the RAR window. RAR is also referred to as Msg2. Next-generation node B (gNB) transmits the RAR on the physical downlink shared channel (PDSCH). PDCCH (physical downlink control channel) scheduling the PDSCH carrying RAR is addressed to RA-radio network temporary identifier (RA-RNTI). RA-RNTI identifies the time-frequency resource (also referred to as physical RA channel (PRACH) occasion or PRACH transmission (TX) occasion or RA channel (RACH) occasion) in which the RA preamble was detected by gNB. If the RAR corresponding to its RA preamble transmission is received, the UE transmits message 3 (Msg3) in the UL grant received in RAR. Msg3 includes messages such as RRC connection request, RRC connection re-establishment request, RRC handover confirm, scheduling request, SI request, etc. It may include the UE identity (i.e., cell-radio network temporary identifier (C-RNTI) or system architecture evolution (SAE)-temporary mobile subscriber identity (S-TMSI) or a random number). After transmitting the Msg3, the UE starts a contention resolution timer. While the contention resolution timer is running, if the UE receives a physical downlink control channel (PDCCH) addressed to C-RNTI included in Msg3, contention resolution is considered successful, the contention resolution timer is stopped, and the RA procedure is completed. While the contention resolution timer is running, if the UE receives a contention resolution MAC control element (CE) including the UE's contention resolution identity (first X bits of common control channel (CCCH) service data unit (SDU) transmitted in Msg3), contention resolution is considered successful, the contention resolution timer is stopped, and the RA procedure is completed. If the contention resolution timer expires and the UE has not yet transmitted the RA preamble for a configurable number of times, the UE goes back to the first step, i.e., select random access resource (preamble / RACH occasion) and transmits the RA preamble. A backoff may be applied before going back to the first step.

[0038] Contention-Free Random Access (CFRA) is also referred to as legacy CFRA or 4-step CFRA. The CFRA procedure is used for scenarios such as handover where low latency is required, timing advance establishment for secondary cell (Scell), etc. 5G node B (gNB) assigns to UE a dedicated Random Access preamble. UE transmits the dedicated RA preamble. gNB transmits the RAR on PDSCH addressed to RA-RNTI. RAR conveys RA preamble identifier and timing alignment information. RAR may also include UL grant. RAR is transmitted in the RAR window similar to the contention-based RA (CBRA) procedure. CFRA is considered successfully completed after receiving the RAR including the RA preamble identifier (RAPID) of the RA preamble transmitted by the UE. In case RA is initiated for beam failure recovery, CFRA is considered successfully completed if PDCCH addressed to C-RNTI is received in search space for beam failure recovery. If the RAR window expires and RA is not successfully completed and the UE has not yet transmitted the RA preamble for a configurable (configured by gNB in RACH configuration) number of times, the UE retransmits the RA preamble.

[0039] Base station broadcasts system information (SI) in a cell. SI is structured into Master Information Block (MIB) and a set of system information blocks (SIBs). System Information is divided into Minimum SI and Other SI. Minimum SI comprises basic information required for initial access and information for acquiring any other SI. Minimum SI consists of MIB and SIB1. Other SI encompasses all SIBs not broadcast in the Minimum SI. Those SIBs can either be periodically broadcast on Downlink-Shared Channel (DL-SCH), broadcast on-demand on DL-SCH, or sent in a dedicated manner on DL-SCH to UEs in RRC_CONNECTED. On-demand SI is broadcast upon request from UEs in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED. UE may request gNB for on-demand SI through msg1 or msg3. On-demand system information is used for receiving positioning related system information also.

[0040] For UEs in RRC_IDLE and RRC_INACTIVE, a request for Other SI triggers a random access procedure where MSG3 includes the SI request message unless the requested SI is associated with a subset of the PRACH resources, in which case MSG1 is used for indication of the requested Other SI. When MSG1 is used, the minimum granularity of the request is one SI message (i.e., a set of SIBs). One RACH preamble and / or PRACH resource can be used to request multiple SI messages, and the gNB acknowledges the request in MSG2. When MSG3 is used, the gNB acknowledges the request in MSG4.

[0041] A self organising network may receive information about random access to perform various optimisations. When the UE performs random access for on-demand system information, especially for the NR advanced features, the information available with the self organising networks (SON) is limited. Similarly, the network may not have information about the random access performed for requesting positioning related system information. This causes considerable short comings for SON.

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

[0043] The 2 Step Contention Based Random Access (2 Step CBRA) procedure involves two main steps. Initially, the User Equipment (UE) transmits a random access preamble on the Physical Random Access Channel (PRACH) and a payload, such as a Medium Access Control Protocol Data Unit (MAC PDU), on the Physical Uplink Shared Channel (PUSCH). This combined transmission is referred to as MsgA. Following the transmission of MsgA, the UE monitors for a response from the network, specifically the gNB, within a configured time window. This network response is known as MsgB. If a Common Control Channel Service Data Unit (CCCH SDU) was included in the MsgA payload, the UE performs contention resolution using the information provided in MsgB. The contention resolution is deemed successful if the contention resolution identity received in MsgB matches the first 48 bits of the CCCH SDU transmitted in MsgA. Alternatively, if a Cell Radio Network Temporary Identifier (C-RNTI) was transmitted in the MsgA payload, the contention resolution is successful if the UE receives a Physical Downlink Control Channel (PDCCH) message addressed to the C-RNTI. Upon successful contention resolution, the random access procedure is considered complete. However, MsgB may include fallback information corresponding to the random access preamble transmitted in MsgA, instead of contention resolution information. If fallback information is received, the UE transmits Msg3 and performs contention resolution using Msg4, as in the traditional Contention Based Random Access (CBRA) procedure. Successful contention resolution in this context also signifies the completion of the random access procedure. In cases where contention resolution fails after fallback, such as after transmitting Msg3, the UE retransmits MsgA. If the configured window for monitoring the network response after MsgA transmission expires without receiving MsgB, including either contention resolution or fallback information, the UE retransmits MsgA. Should the random access procedure remain incomplete after a configurable number of MsgA transmissions, the UE reverts to the 4-step Random Access Channel (RACH) procedure, which involves transmitting only the PRACH preamble.

[0044] The 2 Step Contention Free Random Access (2 Step CFRA) process involves the assignment of dedicated Random Access preambles and PUSCH resources by the gNB to the UE for MsgA transmission. The gNB may also indicate RACH Occasions (ROs) for preamble transmission. Initially, the UE transmits a random access preamble on PRACH and a payload on PUSCH using the contention-free random access resources, which include dedicated preamble, PUSCH resource, and RO. Subsequently, after MsgA transmission, the UE monitors for a response from the network, specifically the gNB, within a configured window. The random access procedure is deemed successfully completed if the UE receives a PDCCH addressed to C-RNTI. Similarly, if the UE receives fallback information corresponding to its transmitted preamble, the procedure is also considered successfully completed. The network has the capability to associate a set of RACH resources with features applicable to a Random Access procedure, such as Network Slicing, (e)RedCap, SDT, and NR coverage enhancement. A set of RACH resources linked to a feature is valid only for random access procedures applicable to at least that feature. Furthermore, a set of RACH resources associated with multiple features is valid only for random access procedures that include at least all of these features. The UE selects the applicable set(s) of RACH resources after uplink carrier selection, either NUL or SUL, and BWP selection, and prior to selecting the RA type.

[0045] System Information handling involves in a cell broadcast environment where a base station disseminates system information (SI). This SI is organized into a master information block (MIB) and a collection of system information blocks (SIBs). System Information is categorized into Minimum SI and Other SI. Minimum SI includes the essential information necessary for initial access and for acquiring any additional SI. It comprises the MIB and SIB1. Other SI includes all SIBs not included in the Minimum SI. These SIBs may be periodically broadcast on the downlink shared channel (DL-SCH), broadcast on-demand on DL-SCH, or transmitted in a dedicated manner on DL-SCH to user equipment (UEs) in the RRC_CONNECTED state. On-demand SI is broadcasted upon request from UEs in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED states. UEs may request on-demand SI from the gNB through msg1 or msg3.

[0046] For UEs in RRC_IDLE and RRC_INACTIVE, a request for Other SI initiates a random access procedure. In scenarios where the requested SI is not linked to a specific subset of Physical Random Access Channel (PRACH) resources, the SI request message is included in MSG3. Conversely, if the requested SI is associated with a subset of PRACH resources, MSG1 is utilized to indicate the requested Other SI. When MSG1 is employed, the minimum granularity of the request is one SI message, which comprises a set of System Information Blocks (SIBs). A single Random Access Channel (RACH) preamble and / or PRACH resource can facilitate the request for multiple SI messages, with the gNB acknowledging the request in MSG2. In cases where MSG3 is used, the gNB provides acknowledgment in MSG4. System Information Blocks (SIBs) are defined across various 3GPP releases. A SIB defined in 3GPP Release 15 is referred to as R15 SIB, while a SIB from Release 16 is termed R16 SIB. Similarly, a SIB from Release 17 is known as R17 SIB, and a SIB from Release 18 is designated as R18 SIB. Collectively, R15 SIB and R16 SIB are referred to as pre-R17 SIB. R17 and R18SIBs include SIB16,SIB17,SIB18,SIB19,SIB20,SIB21,SIB22,SIB23, SIB24,SIB25 etc. provides slicing related information. SIB17 contains configuration for Tracking reference signal. SIB18 contains configuration for Non Public Networks. SIB19 and SIB25 contains satellite assistance information for Non Terrestrial Network (NTN) operations. SIB20,SIB21 and SIB24 helps UE for Multicast and Broadcast Services (MBS). SIB22 is for Air To Ground (ATG). SIB23 is for Sidelink Positioning. This invention provides a mechanism for managing SI requests, ensuring compatibility with multiple 3GPP releases.

[0047] The 5G NR (New Radio) radio access network, also known as NG-RAN (Next Generation Radio Network), comprises a number of NR base stations known as gNBs. These gNBs can connect to each other through the Xn interface and are linked to various core network elements such as the AMF (Access and Mobility Management Function) and UPF (User Plane Function). Furthermore, gNBs can be divided into two physical entities: the CU (Centralized Unit) and the DU (Distributed Unit). The CU supports the higher layers of the protocol stack, including SDAP (Session Data Application Protocol), PDCP (Packet Data Convergence Protocol), and RRC (Radio Resource Control). In contrast, the DU supports the lower layers of the protocol stack, such as RLC (Radio Link Control), MAC (Medium Access Control), and the Physical layer. Each gNB can host multiple cells, serving numerous UEs (User Equipment).

[0048] A significant challenge in NG-RAN is identifying the optimal radio parameters due to the large number of techniques and configuration parameters involved. Operators traditionally resort to manual techniques, like drive tests, to identify these parameters. However, manual parameter tuning is costly and depends on various factors, including the number of users, number of neighbors, maximum throughput in the cell, and average throughput in the cell. Additionally, whenever a neighboring gNB is installed or a new service is introduced, many of these manual operations must be repeated.

[0049] To address this issue, 3GPP has introduced Self-Organizing Networks (SON) techniques in wireless technologies like NR. SON was first introduced in 3GPP Release 9 in LTE. SON solutions are categorized into three types: Self-Configuration, Self-Optimization, and Self-Healing. The SON architecture can be centralized, distributed, or a hybrid solution.

[0050] Self-optimization of RACH (Random Access Channel) aims to minimize the number of attempts on the RACH. The UE (User Equipment) can report detailed information about RACH in the RACH Report to the network. Using this information, the network optimizes various parameters associated with RACH. A list of information that the UE could report in RACH is provided based on NR TS 38.331.

[0051]

[0052] The UE that has requested on-demand system information may log and report the list of System Information Blocks (SIBs) used to the network in a Random Access (RA) Report. The network is informed about the list of SIBs through a single information element called "intendedSIBs." This "intendedSIBs" is defined as a SEQUENCE capable of holding up to a defined maximum number of SIBs in a system information, meaning it can be of size maxSIB. The "intendedSIBs-r17" is a SEQUENCE (SIZE (1...maxSIB)) OF SIB-Type-r17 and is OPTIONAL. In the prior art "intendedSIBs" includes an indication about individual system information types that are requested. But considering the size constraints for reporting, the current design allows the UE to report only following SIBs in the prior art:sibType2, sibType3, sibType4, sibType5, sibType9, sibType10-v1610, sibType11-v1610, sibType12-v1610, sibType13-v1610 and sibType14-v1610. In other words, the current framework for reporting intended SIBs doesn't allow the UE to inform the network whether the UE requested for slicing related system information, NTN related system information, MBS related information, ATG related information, sidelink positioning related information through on demand system information, and this reduces the effectiveness of the self-organizing networks.

[0053] In prior art, UE doesn't inform the network about the request for positioning related system information. "intendedSIBs" does not include positioning system information blocks.

[0054] In the described system, the UE transmits Random Access Channel (RACH) reports to the network through Radio Resource Control (RRC) messages, such as the UE Information Response. Upon receiving the RACH report, the gNodeB Central Unit (gNB CU) may forward it to the gNodeB Distributed Unit (gNB DU) or the Operations, Administration, and Maintenance (OAM) Self-Organizing Network (SON) module. Alternatively, the gNB CU may directly utilize the report to optimize various parameters associated with random access. These parameters include, for example, the number of preambles, the configuration of group A and group B preambles, RACH prioritization information, the contention resolution timer, the number of RACH preambles for two-step RACH, and Physical Uplink Shared Channel (PUSCH) related parameters for two-step RACH. A detailed description of the various parameters that can be included in the random-access report is provided in 3gpp specifications such as TS 38.331.

[0055] The UE is capable of reporting its mobility history information, which includes both PCell and PSCell mobility history data, to the network. This information is subsequently utilized in handover preparations through the Handover Preparation procedures over the NG and XN interfaces. These interfaces provide the target NG-RAN node with a list of previously visited cells and associated per-cell information elements. Additionally, the Handover Preparation procedures initiate the target NG-RAN node to begin the collection and storage of UE history information, thereby enabling the propagation of the collected data. Detailed specifications of mobility history information are outlined in 3GPP standards, such as TS 38331 and TS 38300. An extract from TS 38. 331 is provided below.

[0056]

[0057] RedCap UEs are designed with reduced capabilities to achieve lower complexity compared to non-RedCap UEs. These devices must support a maximum UE channel bandwidth of 20 MHz in Frequency Range 1 (FR1) and 100 MHz in Frequency Range 2 (FR2). In contrast, eRedCap UEs possess even further reduced capabilities, aiming for lower complexity relative to RedCap UEs. For eRedCap UEs, it is mandatory to support a reduced downlink / uplink peak data rate of 10 Mbps. This requirement applies with or without a reduced baseband bandwidth of 5 MHz for unicast Physical Downlink Shared Channel (PDSCH) and Physical Uplink Shared Channel (PUSCH) in FR1. eRedCap feature is designed for the UEs with moderate performance requirements. The eRedCap supporting deviced optimizes network by reducing complexity, increased power efficiency and cost effectiveness. Some of the key features of the eRedCap UEs are enhanced bandwidth flexibility, lower power consumption, simplified device capability and improved mobility and coverage and seamless integration with 5G networks.

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

[0059] FIGURE 1 illustrates a block diagram of a UE for managing random access information in a wireless network according to embodiments disclosed herein. The UE (101) includes a processor (103), a memory (105), an I / O interface (107), and a random access reporting controller (109). Furthermore, the processor (103) of the UE (101) communicates with the memory (105), the I / O interface (107), and the random access reporting controller (109). The processor (103) is configured to execute instructions stored in the memory (105) and to perform various processes. The processor (103) can include one or a plurality of processors, can 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 Artificial Intelligence (AI) dedicated processor such as a neural processing unit (NPU).

[0060] Furthermore, the memory (105) of the UE (101) includes storage locations that can be addressed through the processor (103). The memory (105) is not limited to volatile or non-volatile memory and can include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical discs, floppy discs, flash memories, EPROM, or EEPROM memories can also be included in the memory (105). Further, the memory (105) of the UE (101) can store various information received from network apparatus (405). The UE (101) can store several pieces of information such as trigger of random access using eRedCap feature, intended SIBs, positioning related system information, and the like.

[0061] The I / O interface (107) transmits information between the memory (105) and external peripheral devices, which are input-output devices associated with the UE (101). The I / O interface (107) receives various information from the network apparatus. This interface is used to maintain seamless communication between the UE (101) and external devices, ensuring that data is transmitted and received. Additionally, the I / O interface (107) facilitates the integration of the UE (101) with other network components, enhancing its capability to manage the random access information.

[0062] The random access reporting controller (109) communicates with the I / O interface (107) and the memory (105) for managing random access information in a wireless network. The random access reporting controller (109) is an innovative hardware that is realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0063] The random access reporting controller (109) triggers the random access procedure. This involves initiating a sequence of operations that allow the user equipment (UE) to establish a connection with the network, typically starting with the transmission of a preamble to the base station. Further, the random access reporting controller (109) logs the information about the features related to the random access procedure. This logging process involves capturing data such as the time of access, the specific resources utilized, and any anomalies or failures encountered during the procedure. The features related to the random access procedure can include but are not limited to eRedCap, system information and positioning-related system information. The information about these features are critical for optimizing the access procedure, as they provide insights into the network's configuration and the UE's capabilities. The information about the features related to the random access is included in the RA-InformationCommon and logged in at least one of the Random Access Report (RA-Report), Radio Link Failure Report (RLF Report), Success Handover Report (SHR), Successful PSCell change or addition report (SPR), and Connection Establishment Failure Report (CEF report). These reports are essential for network diagnostics and performance analysis, enabling operators to fine-tune network parameters and improve overall service quality. Further, the random access reporting controller (109) transmits the RRC signaling message to the network apparatus, informing that the eRedCap feature is part of feature combinations that initiated the random access procedure. This signaling message is crucial for the network to understand the context of the access attempt and to allocate resources accordingly. The RRC signaling message can include but is not limited to the UE information response RRC message, which provides detailed information about the UE's identity, capabilities, and current state.

[0064] The random access reporting controller (109) logs the information about the features related to the resources for random access by including the feature combination information when the random access is triggered using feature-specific random access resources related to eRedCap. This involves recording the specific resource blocks and time slots allocated for the access attempt, as well as any priority levels assigned to the eRedCap feature. Further, the random access reporting controller (109) includes the eRedCap feature in the reported feature combination transmitted for the triggered feature combination. This ensures that the network is aware of the specific features that influenced the access procedure, allowing for resource management. Further, the random access reporting controller (109) determines whether the value of a used feature or combination of features differs from the triggered feature combination. This comparison is vital for identifying discrepancies that could indicate potential issues or optimizations in the access process. Further, the random access reporting controller (109) includes the eRedCap feature in the reported feature combination sent in the used feature combination when the eRedCap feature is part of a feature combination associated with a random-access resource utilized in the random access procedure and the value of the used feature or combination of features differs from the triggered feature combination. This detailed reporting allows the network to adjust its configurations dynamically, ensuring that the access procedure remains reliable under varying conditions.

[0065] In an embodiment, the system information includes the information whether the UE (101) requested for slicing related system information, NTN related system information, Multicast and Broadcast Services (MBS) related information, Air To Ground (ATG) related information, and sidelink positioning related information through on demand system information.

[0066] Also, the random access reporting controller (109) detects the request for OSI from the network apparatus. This detection involves monitoring network signals for specific requests that indicate the need for system information blocks (SIBs) to be transmitted. Further, the random access reporting controller (109) generates the IE1 that includes the first list of the requested SIBs. The first list of requested SIBs can include but is not limited to SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, and SIB15. These SIBs provide essential information about the network's configuration, such as cell identity, access restrictions, and scheduling information. Also, the random access reporting controller (109) generates the IE2 that includes the second list of the requested SIBs. The second list of the requested SIBs can include but is not limited to SIB16, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, and SIB25. These SIBs often contain more advanced information, such as positioning data and inter-frequency measurements, which are used for advanced network operations. SIB16 provides slicing related information. SIB17 contains configuration for Tracking reference signal. SIB18 contains configuration for Non Public Networks. SIB19 and SIB25 contains satellite assistance information for Non Terrestrial Network (NTN) operations. SIB20, SIB21 and SIB24 helps UE for MBS. SIB22 is for ATG. SIB23 is for Sidelink Positioning. This means random access controller informs the network whether the UE requested for slicing related system information, NTN related system information, MBS related information, ATG related information, sidelink positioning related information through on demand system information and this helps the network to optimize each of these features. Further, the random access reporting controller (109) transmits the IE1 and the IE2 to the network apparatus for requesting the intended SIBs. During the transmission, the random access reporting controller (109) determines whether the requested SIBs intended by the UE (101) include both pre-R17 SIBs and R17 / R18 SIBs. This determination ensures compatibility and proper interpretation of the SIBs by the network. Further, the random access reporting controller (109) transmits the IE1 including any of the pre-R17 SIBs having R15 or R16 and the IE2 having any of the R17 or R18 SIBs when the requested SIBs intended by the UE (101) do not include both pre-R17 SIBs and R17 / R18 SIBs. This selective transmission helps in managing network resources and avoiding unnecessary data transmission. Also, the random access reporting controller (109) simultaneously transmits the first IE1 and the IE2 to the network apparatus when the requested SIBs intended by the UE (101) include both pre-R17 SIBs and R17 / R18 SIBs. This simultaneous transmission ensures that the UE provides information in a timely manner, facilitating seamless network operations.

[0067] The random access reporting controller (109) transmits the IE1 and IE2 by using the specific enumerated value within the enumeration of SIB-Type to report the request for positioning SIBs distinct from other SIBs which are reported using individual values. While reporting individual values help the network to get a detailed information of the exact system information used by the UE, it will also cause heavy overhead to the UEs since it requires more memory and processing. Reporting individual values increases the signaling overhead. The increase in memory and signaling overhead can even upto almost 50 times. To avoid this overhead, the random access reporting controller (109) just sends a single enumerated value to indicate that positioning SIBs are requested, instead of informing that specific positioning SIBs are requested. This reduces the effectiveness of SON slightly, but considering the reduced overhead on memory and the signaling, this could be still acceptable.

[0068] FIGURE 2 illustrates a block diagram of a network apparatus for managing random access information in a wireless network, according to embodiments disclosed herein.

[0069] The network apparatus (201) includes a processor (203), a memory (205), an I / O interface (207), and a random access reporting controller (209). Furthermore, the processor (203) of the network apparatus (201) communicates with the memory (205), the I / O interface (207), and the random access reporting controller (209). The processor (203) is configured to execute instructions stored in the memory (205) and to perform various processes. The processor (203) can include one or a plurality of processors, can 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 Artificial Intelligence (AI) dedicated processor such as a neural processing unit (NPU).

[0070] Furthermore, the memory (205) of the network apparatus (201) includes storage locations that can be addressed through the processor (203). The memory (205) is not limited to volatile or non-volatile memory and can include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical discs, floppy discs, flash memories, EPROM, or EEPROM memories can also be included in the memory (205). Further, the memory (205) of the network apparatus (201) can store various information received from the UE (101). The network apparatus (201) can store several information such as trigger of random access using eRedCap feature, intended SIBs, positioning related system information and the like that is received in RRC signalling message.

[0071] The I / O interface (207) transmits information between the memory (205) and external peripheral devices, which are input-output devices associated with the network apparatus (201). The I / O interface (207) receives various information from the UE (101). This interface is used to maintain seamless communication between the network apparatus (201) and external devices, ensuring that data is transmitted and received. Additionally, the I / O interface (207) facilitates the integration of the UE (101) with other network components, enhancing its capability to manage the random access information.

[0072] The random access reporting controller (209) communicates with the I / O interface (207), the memory (205), for managing random access information in a wireless network. The random access reporting controller (209) is an innovative hardware that is realized through the physical implementation of both analog and digital circuits, including logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive and active electronic components, as well as optical components.

[0073] The random access reporting controller (209) receives the RRC signaling message from the UE (101) indicating the information about features related to the random access. The features related to the random access include eRedCap, system information and positioning-related system information. The controller is designed to interpret these features. It utilizes advanced techniques to parse the RRC signaling message, ensuring that the information is extracted and processed. The eRedCap system information may include parameters such as reduced capability device indicators, which are used for optimizing network resource allocation and ensuring seamless connectivity for devices with limited capabilities.

[0074] The random access reporting controller (209) receives the IE1 and the IE2 from the UE (101). The random access reporting controller (209) identifies the first list of requested system information blocks (SIBs) and the second list of requested SIBs from the first IE1 and the second IE2. Through these information elements (IEs), the random access controller identifies whether the UE (101) requested for slicing related system information, NTN related system information, MBS related information, ATG related information, sidelink positioning related information through on demand system information. Further, the random access reporting controller (209) optimizes random access parameters based on the first list of requested SIBs and the second list of requested SIBs. This optimization process involves adjusting parameters such as preamble transmission power, backoff intervals, and contention resolution timers to enhance the success rate of random access attempts and reduce latency.

[0075] Also, when the features related to random access include eRedCap as the feature triggering random access or the feature used for random access, then the random access reporting controller (209) optimizes the random access parameters based on the received feature-related random access information. The eRedCap feature is particularly important for devices that operate under constrained conditions, such as IoT devices with limited processing power and battery life. By tailoring the random access parameters to accommodate eRedCap features, the controller ensures that these devices can access the network without compromising their operational constraints. This may involve dynamically adjusting the number of preamble attempts or modifying the access barring parameters to prioritize eRedCap-enabled devices.

[0076] Further, when the single enumerated value is received for positioning system information, then the random access reporting controller (209) optimizes random access parameters based on the received single enumerated value. This enumerated value provides a concise representation of the positioning system information, which may include parameters related to location, timing advance, and reference signal measurements without major overheads of signaling and memory. By leveraging this information, the controller can fine-tune the random access parameters to improve the reliability of positioning services. This optimization is particularly beneficial for applications that require precise location tracking, such as emergency services, navigation systems, and location-based services.

[0077] FIGURE 3 illustrates a flow diagram that illustrates a method for managing random access information in a wireless network by UE according to embodiments disclosed herein.

[0078] At block 301, the method includes triggering by the UE (101) the random access procedure. This triggering can be initiated based on the request from upper layers, such as from application or Non Access Stratum or for internal operations. The UE may utilize a specific technique to determine the optimal timing for initiating the random access procedure, taking into account factors like current network load and historical access success rates. Additionally, the UE may store a history of previous random access attempts to refine its triggering criteria over time.

[0079] At block 303, the method includes logging by the UE (101) the information about the features related to the random access. The features related to the random access can include, but are not limited to, eRedCap feature, system information and positioning-related system information. The logging process involves capturing detailed metadata such as timestamp, frequency band, and cell ID associated with each random access attempt. This information is stored in a secure, non-volatile memory within the UE to ensure persistence across power cycles. Furthermore, the UE may employ compression techniques to store large volumes of logged data without exceeding memory constraints.

[0080] At block 305, the method includes transmitting by the UE (101) the RRC signaling message to the network apparatus (201) including the information about random access (from block 303). The information about the features related to the random access is included in at least one of the RA-Report, the RLF Report, the SHR, the SPR, and the CEF report. The RRC signaling message is formatted according to a predefined protocol that ensures compatibility with various network apparatus configurations. The UE may also include additional diagnostic information, such as error rates or latency metrics, to assist the network apparatus in optimizing its response to the random access request.

[0081] FIGURE 4 illustrates a flow diagram that illustrates the method for managing random access information in the wireless network by network apparatus according to embodiments disclosed herein.

[0082] At block 401, the method includes receiving by the network apparatus (201) the RRC signaling message from the UE (101) indicating the information about features related to random access. The features related to the random access can include, but are not limited to, the eRedCap features, system information, and the positioning-related system information. Upon receipt, the network apparatus parses the message to extract relevant data fields, which are then stored in a centralized database for further analysis. The network apparatus may also perform an initial validation check to ensure the integrity and authenticity of the received data, using cryptographic techniques to prevent unauthorized access or tampering.

[0083] At block 403, the method includes optimizing the random access parameters based on the indicated features. This optimization process involves adjusting parameters such as backoff time, access priority, and resource allocation. The network apparatus may utilize machine learning techniques to predict optimal parameter settings based on historical data and current network conditions. Additionally, the apparatus can dynamically update these parameters in real-time to adapt to changing network environments, thereby improving overall network performance and user experience.

[0084] FIGURE 5 illustrates a flow diagram that illustrates a method for logging and reporting UsedFeatureCombination according to the embodiments as disclosed herein.

[0085] At block 501, the method includes performing the random access by the UE (101) using the random-access resources associated with the eRedCap. The UE (101) selects appropriate random-access resources based on its current location, network conditions, and the specific requirements of the eRedCap feature. The selection process may involve a decision-making technique that evaluates multiple resource options to identify the suitable one for the current context. The UE (101) then initiates the random access procedure using the chosen resources, ensuring compliance with network protocols and standards.

[0086] At block 503, the method includes including by the UE (101) the eRedCap in the usedFeatureCombination in the RA-Information Common. This inclusion involves updating the RA-Information Common data structure with the relevant eRedCap feature details. The UE (101) may also include additional context-specific data, such as the duration of the random access attempt and any encountered anomalies, to provide a comprehensive view of the used feature combination. This information is then prepared for transmission to the network apparatus as part of the reporting process.

[0087] At block 505, the method includes reporting by the UE (101) the logged information about the eRedCap in usedFeatureCombination to the network apparatus (201) in at least one of the RA report, the CEF report, the RLF report, and the SHR. The reporting process involves formatting the logged information according to the specific requirements of each report type, ensuring compatibility with the network apparatus's data processing systems. The UE (101) may also implement error-checking mechanisms to verify the completeness of the reported data before transmission. Once prepared, the reports are sent to the network apparatus using a secure communication channel to prevent data interception or loss.

[0088] FIGURE 6 illustrates a flow diagram that illustrates a method for logging and reporting triggeredFeatureCombination according to the embodiments as disclosed herein.

[0089] At block 601, the method includes triggering by the UE (101) the random access using the eRedCap. The triggering process is initiated based on predefined criteria, such as network demand or specific application requirements, which dictate the need for random access. The UE (101) evaluates these criteria using a decision-making technique that considers both current and historical network data to determine the optimal timing for triggering the random access. Once triggered, the UE (101) proceeds with the random access procedure, ensuring adherence to network protocols and standards.

[0090] At block 603, the method includes including by the UE (101) the eRedCap in triggeredFeatureCombination in the RA-Information Common. This inclusion involves updating the RA-Information Common data structure with the relevant eRedCap feature details. The UE (101) may also include additional context-specific data, such as the duration of the random access attempt and any encountered anomalies, to provide a comprehensive view of the triggered feature combination. This information is then prepared for transmission to the network apparatus as part of the reporting process.

[0091] At block 605, the method includes reporting by the UE (101) the logged information about the eRedCap in the triggeredFeatureCombination in at least one of the RA report, CEF report, RFF report, and SHR. The reporting process involves formatting the logged information according to the specific requirements of each report type, ensuring compatibility with the network apparatus's data processing systems. The UE (101) may also implement error-checking mechanisms to verify the completeness of the reported data before transmission. Once prepared, the reports are sent to the network apparatus using a secure communication channel to prevent data interception or loss.

[0092] In an embodiment, if the random access is triggered by eRedCap, UE (101) sets triggeredFeatureCombination to indicate that random access is triggered by eRedCap feature. UE (101) informs network apparatus (201) that eRedCap is part of the feature combinations that triggered random access. UE includes eRedCap in the reportedfeaturecombinations send for triggeredFeatureCombination.

[0093] In an embodiment, if the value of used feature or combination of features is different from the triggeredFeatureCombination and if eRedCap is part of the FeatureCombination associated to the random-access resource used in the random-access procedure, UE (101) includes eRedCap in the reportedFeaturecombinations send in triggeredFeatureCombination.

[0094] In an embodiment, table 2 below is for TS 38.331.

[0095]

[0096] The UE (101) reports the logged triggeredFeatureCombination and usedFeatureCombination to the network apparatus (201) in the RA-Report, the RLF and the SHR using UEInformationResponse RRC message.

[0097] FIGURE 7 illustrates a sequence diagram that illustrates reporting information for eRedCap, system information and positioning system information to gNB according to the embodiments as disclosed herein. At step S1, the UE (101) receives a UE information request from the network apparatus (201). The UE information request can include, but is not limited to, a connestfailreportreq, ra-reportreq, or rlf-reportreq that is set to true. The connestfailreq is a request to report connection establishment failure information that indicates a failure of establishing a connection between the UE (101) and the network apparatus (201). Similarly, the ra-reportreq is a request to report the random access related information, and the rlf-reportreq is a request to report the radio link failure information. At step S2, the UE (101) includes the information related to eRedCap, system information and positioning system information for the SON in response to receiving the UE information request message. At step S3, the UE (101) sends a UE information response message to the network apparatus (201) indicating the logged information, which is the information related to eRedCap, system information and positioning system information. Further, at step S4, the network apparatus (201) optimizes the random access parameters based on the eRedCap-related information received from the UE (101).

[0098] FIGURE 8 illustrates a flow diagram that illustrates a method for logging the information related to intended system information in RA-InformationCommon according to the embodiments as disclosed herein. At block 801, the method includes performing by the UE (101) the random access procedure for requesting the on-demand system information. At block 803, the method includes including whether the UE (101) requested for at least one of slicing related system information, NTN related system information, MBS related information, ATG related information, sidelink positioning related information through on demand system information by including information about the corresponding SIB in new information element. Further, including a single enumerated value, posSIB if the UE (101) requested for one or multiple positioning system information.. At block 805, the method includes reporting by the UE (101) the logged information indicating the IE1 and IE2 to the network apparatus (201) in the RA report, the CEF report, the RLF report, the SHR.

[0099] In an embodiment, the UE (101), which has initiated the random access procedure to request on-demand system information, informs the network apparatus (201) of the intended SIBs by sending one or two information elements in RA-InformationCommon to the network apparatus (201) (as part of RA-Report, RLF Report, SHR,SPR, CEF report, etc.), which indicates the system information blocks it wanted to receive as a result of System Information Request using one of the following embodiments. In an embodiment, when the UE (101) has requested OSI since it wanted to receive any of the following SIBs such as SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, SIB15, SIB16, SIB17, SIB18, SIB19, SIB20, the UE (101) sends the list of these SIBs in one information element IE1 (such as intendedSIBs-r17). If the OSI was also requested to receive any of the other SIBs such as SIB21, SIB22, SIB23, SIB24, SIB25, the UE (101) sends the list of those SIBs in another information element IE2 (such as intendedSIBs-r18 below). The UE (101) sends R16 SIBs and a subset of R17 SIBs in one information element (such as intendedSIBs-r17) and a subset of R17 SIBs and R18 SIBs in another information element (such as intendedSIBs-r18). IE1 is a SEQUENCE which can hold up to maxSIB, the maximum number of SIBs the UE (101) can request in one SI message. The UE (101) includes only a maximum of maxSIB / 2 elements in IE1 stored and sent to the network in RA-InformationCommon.

[0100] An example structure based on TS 38.331 is given below table 3.

[0101]

[0102] In an embodiment, if OSI was sent to request SIB1, it is included in IE2 (such as intendedSIBs-r18). In an alternate embodiment, SIB21 is included in intendedSIBs-r17, and if the UE (101) has sent OSI to request SIB19, the UE (101) doesn't inform the network apparatus (201) that SIB19 is requested in RA-InformationCommon. In yet another alternative, SIB21 is included in intendedSIBs-r17, and if the UE (101) has sent OSI to request SIB19, it is included in another information element (such as intendedSIBs-r18). In an embodiment, if OSI was sent to request SIB1, it is included in IE2 (such as intendedSIBs-r18). A gNB (201) (hereinafter the gNB and the network apparatus are interchangeably used), which receives RA-InformationCommon and is performing SON based on the received information, combines both the sequences IE1 and IE2 and identifies the list of all SIBs requested and performs required optimizations.

[0103] In an embodiment, when the UE (101) has requested OSI since it wanted to receive any of the following SIBs, such as SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, SIB15, then the UE (101) sends the list of these SIBs in one information element, IE1 (such as intendedSIBs-r17). If the OSI was also requested to receive any of the other SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, SIB25, then the UE (101) sends the list of those SIBs in another information element, IE2 (such as intendedSIBs-r18 below). The UE (101) sends R15 or R16 SIBs in one information element (such as intendedSIBs-r17) and any R17 SIBs and R18 SIBs in another information element (such as intendedSIBs-r18). Both IE1 and IE2 may be reported simultaneously if the requested SIBs intended by the UE (101) contain both pre-R17 SIBs (R15 or R16 SIBs) and R17 / R18 SIBs.

[0104] An example structure based on TS 38.331 is given below table 4.

[0105]

[0106] In an embodiment, if OSI was send to request SIB1, it is included in IE2 (such as intendedSIBs-r18).

[0107] In an embodiment, the UE (101) informs the network apparatus (201) that the OSI was send for requesting for positioning system information. The UE (101) can use a specific value in the enumeration of SIB-Type-r18 to indicate the same.

[0108] An example specification extract is given below table 5.

[0109]

[0110] Enumerated pos-sib indicates that the UE (101) requested SI message for receiving positioning SIBs.

[0111] Alternatively, UE may use a specific value in the enumeration of SIB-Type-r17 to indicate that the OSI is for positioning system information (as shown table 6 below).

[0112]

[0113] Here, also, enumerated pos-sib indicates that the UE (101) requested an SI message for receiving positioning SIBs. The gNB (201), which receives RA-InformationCommon and is performing SON based on the received information, combines the IE1 and the IE2 and identifies the list of all SIBs requested and performs required optimizations.

[0114] In an embodiment, the gNB (201) identifies that OSI is requested for positioning SIB based on the presence of SIB-Type-r17 and SIB-Type-r18. If both SIB-Type-r17 and SIB-Type-r18 are not present, then the UE (101) identifies that the system information requested is for positioning SIBs.

[0115] A description of intendedSIBs according to 3GPP TS 38331 is given below. The intendedSIBs field indicates the SIB(s) the UE (101) wanted to receive as a result of the on-demand SI request (when the RA procedure is used as an SI request) initiated by the UE (101). That is, it indicates the one(s) of the SIB(s) in the SI message(s) requested to be broadcast that the UE (101) was interested in. If UE (101) wanted to receive any of SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, the UE (101) sends intendedSIBs-r17. However, the UE (101) sends intendedSIBs-r18 if the UE (101) wanted to receive positioning SIB; it includes posSIB.

[0116] IE1 can hold up to maxSIB elements in the SEQUENCE, i.e., the maximum number of SIBs the UE (101) can request in one SI message. But the UE (101) includes only a maximum of maxSIB / 2 elements in IE1 stored and sent to the network in RA-InformationCommon and includes the remaining elements in IE2.

[0117] In an embodiment, when the UE (101) has requested OSI since it wanted to receive any one of the following SIBs: SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, UE may send the list of these SIBs in one information element IE1 (such as intendedSIBs-r17). If the OSI was requested to receive any of the other SIBs, such as SIB16, SIB15, SIB16, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, SIB25, then the UE (101) sends the list of those SIBs in another information element IE2 (such as intendedSIBs-r18 below), and IE2 is encoded as a BITSTRING.

[0118] If OSI is containing NR R15 / R16 SIBs, UE sends a list of SIB identifiers (such as intendedSIBs-r17). If OSI contains any SIBs defined in NR R17, R18, or later 3GPP releases, the UE (101) sends a bitstring which identifies both R17 SIBs, R18 SIBs, and later versions of NR.

[0119] An example structure based on TS 38.331 is given below table 7.

[0120]

[0121] In an embodiment, if the OSI was sent to request SIB1, it is included in IE2 (such as intendedSIBs-r18). IE1 can hold up to maxSIBs, the maximum number of SIBs the UE (101) can request in one SI message. But the UE (101) includes only a maximum of maxSIB / 2 elements in IE1, stored and sent to the network in RA-InformationCommon. The gNB (201), which receives RA-InformationCommon and is performing SON based on the received information, combines IE1 and IE2 and identifies the list of all SIBs requested and performs required optimizations.

[0122] Further, in an embodiment, when the UE (101) has requested OSI since it wanted to receive only one of the following SIBs: SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, then the UE (101) may send the list of these SIBs in one information element IE1 (such as intendedSIBs-r17). If the OSI request included any of the other SIBs, such as SIB16, SIB15, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, SIB25, then the UE (101) sends the list of all the SIBs (including SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14) in another information element, the IE2 (such as intendedSIBs-r18 below), and IE2 is encoded as a BITSTRING.

[0123] When the OSI only contains NR R15 / R16 SIBs, the UE either sends a list of SIB identifiers (such as intendedSIBs-r17) or a BITSTRING. If OSI contains any SIBs defined in NR R17, R18, or later 3GPP releases, the UE sends a BITSTRING which identifies both R17 SIBs, R18 SIBs, and later versions of NR.

[0124] An example structure based on TS 38.331 is given below table 8.

[0125]

[0126] In an embodiment, if OSI was sent to request SIB1, it is included in IE2 (such as intendedSIBs-r18). In an embodiment, bits 6, 7, and 8 of the BITSTRING are never set to one. In an alternative embodiment, bit 6 indicates SIB9, bit 7 indicates SIB10, bit 8 indicates SIB11, bit 9 indicates SIB12, etc.

[0127] If the UE (101) is sending intendedSIBs1-r18, it may not send intendedSIBs-r17.

[0128] In an embodiment, one bit of intendedSIBs1 may be used to indicate that the UE has requested positioning system information.

[0129] The gNB (201), which receives RA-InformationCommon and is performing SON based on the received information, combines IE1 and IE2 and identifies the list of all SIBs requested and performs required optimizations.

[0130] In an embodiment, the UE (101) reports the list of positioning system information blocks which it has intended to receive while sending On-Demand System Information Request in RA-InformationCommon. This may be included in a single information element within the RA-InformationCommon. If the UE (101) reports positioning system information blocks in RA-InformationCommon, it will not include other (non-positioning) system information blocks.

[0131] FIGURE 9 illustrates a sequence diagram that illustrates reporting intended SIBs to gNB according to the embodiments as disclosed herein. At step S1, the UE (101) receives the UE information request from the network apparatus (201). The UE information request can include, but is not limited to, a connestfailreportreq, ra-reportreq, or rlf-reportreq that is set to true. The connestfailreq is a connection establishment failure request message that indicates a failure of establishing a connection between the UE (101) and the network apparatus (201). Similarly, the ra-reportreq is the random access request message, and the rlf-reportreq is the radio link failure request message. At step S2, the UE (101) includes or logs the IE1 and the IE2 for the intended SIBs in the RA-information common. At step S3, the UE (101) sends the UE Information Responseto the network apparatus (201) by including RA-InformationCommon. At step S4, the network apparatus (201) optimizes the random access parameters based on the information received from the UE (101) in the UE information response message.

[0132] FIGURE 10A illustrates the flow diagram that illustrates the method for handling MHI when the UE deregisters and registers on the same network according to the embodiments as disclosed herein. At block 901, the method includes logging by the UE (101) a mobility history information (MHI). At block 903, the method includes deregistering by the UE (101) from the network apparatus (201). At block 905, the method includes retaining or keeping the logged information about the MHI. At block 907, the method includes registering by the UE (101) on the same network apparatus (201). Upon registering, at block 909, the method includes keeping or retaining by the UE (101) the logged MHI and further updating the visited cells and the visited PScells in the MHI.

[0133] FIGURE 10B illustrates a flow diagram that illustrates a method for handling MHI when the UE deregisters and registers on a different network according to the embodiments as disclosed herein.

[0134] At block 911, the method includes logging by the UE (101) a mobility history information (MHI).

[0135] At block 913, the method includes deregistering by the UE (101) from the network apparatus (201).

[0136] At block 915, the method includes retaining or keeping by the UE (101) the logged information about the MHI.

[0137] At block 917, the method includes registering by the UE (101) on a different network apparatus (201).

[0138] Upon registering at block 919, the method includes releasing by the UE (101) the logged MHI.

[0139] In an embodiment, an NR UE (101) which has stored mobility history information (MHI) releases the same upon registering on a different PLMN or a different SNPN or a different PNI-NPN. If the UE (101) was registered on a PLMN and registers on an SNPN, it releases the mobility history information. If the UE (101) was registered on a PLMN and registers on a PNI-NPN, it releases the mobility history information. If the UE (101) was registered on an SNPN and registers on a PLMN, it releases the mobility history information. If the UE was registered on a PLMN and registers on a PNI-NPN, it releases the mobility history information. If the UE (101) was registered on a PNI-NPN and registers on an SNPN, it releases the mobility history information. If the UE (101) was registered on a PLMN and registers on a PLMN, it releases the mobility history information.

[0140] For example, consider the UE (101) which has camped on a PLMN1. If the UE (101) deregisters from PLMN1, the UE keeps the MHI. Further, if the UE (101) registers on an SNPN SNPN2, the UE (101) releases MHI.

[0141] In yet another example, consider the UE (101) which has camped on an SNPN SNPN1. Further, if the UE (101) deregisters from SNPN1, then the UE (101) keeps the MHI. Further, when the UE (101) registers on a non-SNPN cell in PLMN1, then the UE (101) releases MHI.

[0142] The UE (101) releases MHI upon registration on a new network while it still keeps the MHI upon deregistration from the network. Upon registration on a different PLMN or SNPN or PNI-NPN or a different type of network (a PLMN or SNPN or PNI-NPN can be considered as a type of network in the context of this invention), the UE (101) releases the MHI.

[0143] This may be represented in TS 38.331 as below table 9.

[0144]

[0145] FIGURE 11 illustrates a block diagram illustrating a structure of a UE according to the embodiments as disclosed herein. A UE of FIG. 11 may correspond to the UE of FIG. 1.

[0146] As shown in FIG. 11, the UE according to an embodiment may include a transceiver 1110, a memory 1120, and a processor (e.g. controller) 1130. The transceiver 1110, the memory 1120, and the processor 1130 of the UE may operate according to a communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. In addition, the processor 1130, the transceiver 1110, and the memory 1120 may be implemented as a single chip. Also, the processor 1130 may include at least one processor.

[0147] The transceiver 1110 collectively refers to a UE receiver and a UE transmitter, and may transmit / receive a signal to / from a base station. The signal transmitted or received to or from the base station may include control information and data. The transceiver 1110 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 1110 and components of the transceiver 1110 are not limited to the RF transmitter and the RF receiver.

[0148] Also, the transceiver 1110 may receive and output, to the processor 1130, a signal through a wireless channel, and transmit a signal output from the processor 1130 through the wireless channel.

[0149] The memory 1120 may store a program and data required for operations of the UE. Also, the memory 1120 may store control information or data included in a signal obtained by the UE. The memory 1120 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0150] The processor 1130 may control a series of processes such that the UE operates as described above. For example, the transceiver 1110 may receive a data signal including a control signal transmitted by the base station, and the processor 1130 may determine a result of receiving the control signal and the data signal transmitted by the base station.

[0151] FIGURE 12 illustrates a block diagram illustrating a structure of a base station according to the embodiments as disclosed herein. A base station of FIG. 12 may correspond to the network apparatus of FIG. 2.

[0152] As shown in FIG. 12, the base station according to an embodiment may include a transceiver 1210, a memory 1220, and a processor (e.g. controller) 1230. The transceiver 1210, the memory 1220, and the processor 1230 of the base station may operate according to a communication method of the base station described above. However, the components of the base station are not limited thereto. For example, the base station may include more or fewer components than those described above. In addition, the processor 1230, the transceiver 1210, and the memory 1220 may be implemented as a single chip. Also, the processor 1230 may include at least one processor.

[0153] The transceiver 1210 collectively refers to a base station receiver and a base station transmitter, and may transmit / receive a signal to / from a terminal. The signal transmitted or received to or from the terminal may include control information and data. The transceiver 1210 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 1210 and components of the transceiver 1210 are not limited to the RF transmitter and the RF receiver.

[0154] Also, the transceiver 1210 may receive and output, to the processor 1230, a signal through a wireless channel, and transmit a signal output from the processor 1230 through the wireless channel.

[0155] The memory 1220 may store a program and data required for operations of the base station. Also, the memory 1220 may store control information or data included in a signal obtained by the base station. The memory 1220 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0156] The processor 1230 may control a series of processes such that the base station operates as described above. For example, the transceiver 1210 may receive a data signal including a control signal transmitted by the terminal, and the processor 1230 may determine a result of receiving the control signal and the data signal transmitted by the terminal.

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

Claims

1.A user equipment (UE) in a wireless communication system, the UE comprising:a transceiver; anda controller coupled to the transceiver, and configured to:perform a random-access procedure, andtransmit, to a base station, a message including random-access information,wherein the random-access information includes first information for indicating at least one feature that triggers the random-access procedure and second information for indicating at least one feature associated with used random-access resources, andwherein, in case that the random-access procedure is triggered by a feature of enhanced reduced capabilities (eRedCap), the first information includes an indicator of eRedCap.2.The UE of Claim 1, wherein, in case that a value of the second information is different from the first information and the feature of eRedCap is associated with a random-access resource used in the random-access procedure, the second information includes the indicator of eRedCap.3.The UE of Claim 1, wherein the controller is further configured to:identify that the feature of eRedCap is applicable for the random-access procedure,wherein the UE is a UE with enhanced reduced capabilities (eRedCap).4.The UE of Claim 1,wherein the message is a UE information response message,wherein the first information is triggeredFeatureCombination information, andwherein the second information is usedFeatureCombination information.5.The UE of Claim 1,wherein the random-access information includes at least one of third information indicating a first system information block (SIB) that the UE want to receive or fourth information indicating a second SIB that the UE want to receive.6.The UE of Claim 5, wherein a purpose of the random-access procedure is to request on-demand system information.7.The UE of Claim 5,wherein the first SIB comprises at least one of a SIB type 2, a SIB type 3, a SIB type 4, a SIB type 5, a SIB type 9, a SIB type 10, a SIB type 11, a SIB type 12, a SIB type 13, a SIB type 14, or a positioning SIB, andwherein the second SIB comprises at least one of a SIB type 15, a SIB type 16, a SIB type 17, a SIB type 18, a SIB type 19, a SIB type 20, a SIB type 21, a SIB type 22, a SIB type 23, a SIB type 24, or a SIB type 25.8.A method performed by a user equipment (UE) in a wireless communication system, the method comprising:performing a random-access procedure; andtransmitting, to a base station, a message including random-access information,wherein the random-access information includes first information for indicating at least one feature that triggers the random-access procedure and second information for indicating at least one feature associated with used random-access resources, andwherein, in case that the random-access procedure is triggered by a feature of enhanced reduced capabilities (eRedCap), the first information includes an indicator of eRedCap.9.The method of Claim 8, wherein, in case that a value of the second information is different from the first information and the feature of eRedCap is associated with a random-access resource used in the random-access procedure, the second information includes the indicator of eRedCap.10.The method of Claim 8, further comprising:identifying that the feature of eRedCap is applicable for the random-access procedure,wherein the UE is a UE with enhanced reduced capabilities (eRedCap).11.The method of Claim 8,wherein the message is a UE information response message,wherein the first information is triggeredFeatureCombination information, andwherein the second information is usedFeatureCombination information.12.The method of Claim 8,wherein the random-access information includes at least one of third information indicating a first system information block (SIB) that the UE want to receive or fourth information indicating a second SIB that the UE want to receive.13.The method of Claim 12, wherein a purpose of the random-access procedure is to request on-demand system information.14.The method of Claim 12,wherein the first SIB comprises at least one of a SIB type 2, a SIB type 3, a SIB type 4, a SIB type 5, a SIB type 9, a SIB type 10, a SIB type 11, a SIB type 12, a SIB type 13, a SIB type 14, or a positioning SIB, andwherein the second SIB comprises at least one of a SIB type 15, a SIB type 16, a SIB type 17, a SIB type 18, a SIB type 19, a SIB type 20, a SIB type 21, a SIB type 22, a SIB type 23, a SIB type 24, or a SIB type 25.

Images