Method and apparatus for determining and reporting random access information for an automatic configuration network in a wireless communication system

Abstract

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

Description

Technology Field

[0001] This application claims the benefit based on Indian provisional application 202441003294 filed January 17, 2024, the contents of which are incorporated herein by reference. The proposed embodiments relate to satellite communication. More specifically, this disclosure relates to the determination and reporting of random access information for a self-optimization network. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz (THX) band (e.g., the 3 terahertz band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC), technologies included beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands; support for various numerologies (such as operating multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources; initial access techniques to support multi-beam transmission and broadband; the definition and operation of Band-Width Parts (BWP); Low Density Parity Check (LDPC) codes for high-volume data transmission; new channel coding methods such as Polar Codes for the reliable transmission of control information; and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes to expand network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies. The problem to be solved

[0008] The primary objective of the embodiments in this specification is to determine and report random access information in a self-organizing network (SON). Another objective of the present invention is to manage random access information in a wireless network.

[0009] Another objective of the present invention is to report random access triggered using a combination of features associated with enhanced reduced capabilities (eRedCap) or using eRedCap-related random access resources.

[0010] Another objective of the present invention is to request SIBs intended within the first information element or the second information element.

[0011] Another objective of the present invention is to inform the network that OSI is being transmitted to request positioning system information by using a specific value within the enumeration of SIB-Type-r17. means of solving the problem

[0012] In one embodiment, the objectives are achieved by providing a method for managing random access information in a wireless network. The method includes the step of triggering a random access procedure by user equipment (UE). Additionally, the method includes the step of logging information regarding features related to the random access procedure by the UE. Features related to the random access procedure include eRedCap, system information, and positioning-related system information. Additionally, the method includes the step of transmitting a radio resource control (RRC) signaling message containing information regarding features related to the random access procedure by the UE to a network device.

[0013] In another embodiment, the objectives are achieved by providing a method for managing random access information in a wireless network. The method includes the step of receiving an RRC signaling message from a UE by a network device that indicates information regarding features related to random access. Features related to random access include enhancedRedCap (eRedCap), system information, and positioning-related system information. Additionally, the method includes the step of optimizing random access parameters based on the features received by the network device.

[0014] In another embodiment, 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 control unit coupled to communicate with the processor. Additionally, the random access reporting control unit triggers a random access procedure. Additionally, the random access reporting control unit logs information regarding features related to the random access procedure. Features related to the random access procedure include enhancedRedCap (eRedCap), system information, and positioning-related system information. Additionally, the random access reporting control unit transmits an RRC signaling message containing information regarding features related to the random access procedure to a network device.

[0015] In another embodiment, the objectives are achieved by providing a network device for managing random access information in a wireless network. The network device includes a processor and a random access reporting control unit coupled to communicate with the processor. The random access reporting control unit receives an RRC signaling message from a UE indicating information regarding features related to random access. Features related to random access include eRedCap, system information, and positioning-related system information. Additionally, the random access reporting control unit optimizes random access parameters based on the information regarding the received features.

[0016] These and other aspects of the embodiments in this specification will be better understood and grasped when considered together with the following description and the accompanying drawings. However, it should be understood that while the following description presents preferred embodiments and many specific details thereof, they are given as examples rather than limitations. Many changes and modifications may be made within the scope of the embodiments in this specification. Effects of the invention

[0017] The embodiments of the present disclosure provide efficient communication methods in a wireless communication system. Brief explanation of the drawing

[0018] These and other features, aspects, and advantages of the embodiments are illustrated in the accompanying drawings, and the same reference numerals throughout the drawings indicate corresponding parts in various drawings. The embodiments of this specification will be better understood from the following description with reference to the drawings: FIG. 1 illustrates a block diagram of a UE for managing random access information in a wireless network according to embodiments disclosed in this specification. FIG. 2 illustrates a block diagram of a network device for managing random access information in a wireless network according to embodiments disclosed in this specification. FIG. 3 illustrates a flowchart illustrating a method for managing random access information in a wireless network by a UE according to embodiments disclosed in this specification. FIG. 4 illustrates a flowchart illustrating a method for managing random access information in a wireless network by a network device according to embodiments disclosed in this specification. FIG. 5 illustrates a flowchart illustrating a method for logging and reporting UsedFeatureCombination according to embodiments as disclosed in this specification. FIG. 6 illustrates a flowchart illustrating a method for logging and reporting triggeredFeatureCombination according to embodiments as disclosed in this specification. FIG. 7 illustrates a sequence diagram illustrating reporting information about eRedCap, system information, and positioning system information to gNB according to embodiments as disclosed in this specification. FIG. 8 illustrates a flowchart illustrating a method for logging information related to intended system information to RA-InformationCommon according to embodiments as disclosed in this specification. FIG. 9 illustrates a sequence diagram illustrating reporting intendedSIBs to gNB according to embodiments as disclosed in this specification. FIG. 10a illustrates a flowchart illustrating a method for handling an MHI when a UE unregisters and registers on the same network, according to embodiments as disclosed in this specification. FIG. 10b illustrates a flowchart illustrating a method for handling an MHI when a UE unregisters and registers in different networks, according to embodiments as disclosed in this specification. FIG. 11 illustrates a block diagram illustrating the structure of a UE according to embodiments as disclosed in the present specification. FIG. 12 illustrates a block diagram illustrating the structure of a base station according to embodiments as disclosed in the present specification. It may be noted that, whenever possible, the same reference numbers are used to denote the same elements in the drawings. Additionally, a person skilled in the art will understand that the elements in the drawings are illustrative for simplification and may not necessarily be drawn to scale. For example, the dimensions of some elements in the drawings may be exaggerated compared to others to improve understanding of the embodiments of the invention. Furthermore, elements may be indicated by conventional symbols in the drawings, and the drawings may only show the specific details relevant to understanding the embodiments of the invention so as not to obscure the drawings with details that would be readily apparent to a person skilled in the art who benefits from the description in this specification. Specific details for implementing the invention

[0019] It may be noted that, whenever possible, the same reference numbers are used to denote the same elements in the drawings. Additionally, a person skilled in the art will understand that the elements in the drawings are illustrative for simplification and may not necessarily be drawn to scale. For example, the dimensions of some elements in the drawings may be exaggerated compared to others to improve understanding of the embodiments of the invention. Furthermore, elements may be indicated by conventional symbols in the drawings, and the drawings may only show the specific details relevant to understanding the embodiments of the invention so as not to obscure the drawings with details that would be readily apparent to a person skilled in the art who benefits from the description in this specification.

[0020] As is customary in the art, embodiments are described and illustrated in terms of the described functions or blocks performing the functions. These blocks, referred to herein as managers, units, modules, hardware components, etc., 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, etc., and may optionally be driven by firmware and software. For example, the circuits may be implemented on one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuits constituting the blocks may be implemented by dedicated hardware, by a processor (e.g., one or more programmed microprocessors and related circuits), or by a combination of dedicated hardware for performing some functions of the blocks and a processor for performing other functions of the blocks. Each block of the embodiments may be physically separated into two or more interacting discrete blocks without going beyond the scope of the proposed method. Likewise, the blocks of the embodiments can be physically combined into more complex blocks without going beyond the scope of the proposed method.

[0021] The accompanying drawings are used to aid in the easy understanding of 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 interpreted to extend to any modifications, equivalents, and substitutions in addition to those specifically described in the accompanying drawings. Although terms such as "first," "second," etc., are used in this specification to describe various elements, these elements are not limited by these terms. These terms are generally used to distinguish one element from another.

[0022] Advancements in wireless communication systems have led to the development of 5G networks, which aim to provide enhanced connectivity, higher data transmission rates, and improved reliability. A critical component of 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 reset, transmission of scheduling requests, addition / modification of secondary cell groups (SCG), beam failure recovery, and transmission of data or control information by asynchronous user equipment (UE) in the RRC_CONNECTED state. Despite its importance, the RA procedure presents several challenges that can affect the overall performance and efficiency of 5G networks.

[0023] In 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) within the RAR window. The RAR is also referred to as Msg2. The next-generation node B (gNB) transmits the RAR over the physical downlink shared channel (PDSCH). The physical downlink control channel (PDCCH) that schedules the PDSCH carrying the RAR is addressed by the radio network temporary identifier (RA-RNTI). The RA-RNTI identifies the time-frequency resource (also referred to as a physical RA channel (PRACH) occasion, PRACH transmit (TX) opportunity, or RA channel (RACH) opportunity) where the RA preamble was detected by the gNB. When a RAR is received that corresponds to his RA preamble transmission, the UE transmits Message 3 (Msg3) from the UL grant received in the RAR. Msg3 contains messages such as an RRC connection request, an RRC connection reset request, an RRC handover acknowledgment, a scheduling request, an SI request, etc. Msg3 may contain the UE identity (i.e., a Cell-Radio Network Temporary Identifier (C-RNTI), a System Architecture Evolution (SAE)-Temporary Mobile Subscriber Identity (S-TMSI), or a random number). After transmitting Msg3, the UE starts a contention resolution timer. While the contention resolution timer is running, if the UE receives a PDCCH addressed by the C-RNTI included in Msg3, the contention resolution is considered successful, the contention resolution timer is stopped, and the RA procedure is completed.While the competition resolution timer is running, if the UE receives a competition resolution MAC (medium access control) CE (control element) containing the UE's competition resolution identity (the first X bits of the common control channel (CCCH) service data unit (SDU) transmitted in Msg3), competition resolution is considered successful, the competition resolution timer is stopped, and the RA procedure is completed. If the competition resolution timer expires and the UE has not yet transmitted the RA preamble a set number of times, the UE returns to the first step, that is, selects a random access resource (preamble / RACH opportunity) and transmits the RA preamble. Backoff may be applied before returning to the first step.

[0024] Contention-free random-access (CFRA) is also referred to as legacy CFRA or 4-phase CFRA. The CFRA procedure is used in scenarios requiring low latency, such as handovers and timing advance setups for secondary cells (Scell). A 5G Node B (gNB) allocates a dedicated random access preamble to a UE. The UE transmits a dedicated RA preamble. The gNB transmits a RAR on a PDSCH addressed by the RA-RNTI. The RAR carries the RA preamble identifier and timing alignment information. The RAR may also include UL grants. Similar to the contention-based RA (CBRA) procedure, the RAR is transmitted within a RAR window. CFRA is considered successfully completed upon receiving a RAR containing the RA preamble identifier (RAPID) of the RA preamble transmitted by the UE. When RA is initiated for beam failure recovery, CFRA is considered successfully completed when a PDCCH addressed to C-RNTI is received in the seek 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 a number of times configurable (configured in the RACH configuration by the gNB), the UE retransmits the RA preamble.

[0025] The base station broadcasts system information (SI) from the cell. SI is structured into a set of master information blocks (MIBs) and system information blocks (SIBs). System information is divided into minimum SI and other SI. Minimum SI contains basic information required for initial access and information for obtaining other SI. Minimum SI consists of MIB and SIB1. Other SI includes all SIBs that are not broadcast in minimum SI. These SIBs may be broadcast periodically over the Downlink Shared Channel (DL-SCH), broadcast on-demand over the DL-SCH, or transmitted exclusively over the DL-SCH to UEs in the RRC_CONNECTED state. On-demand SI is broadcast upon request from UEs in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state. A UE may request on-demand SI from the gNB via msg1 or msg3. On-demand system information is also used to receive positioning-related system information.

[0026] For UEs in the RRC_IDLE and RRC_INACTIVE states, unless the requested SI is associated with a subset of PRACH resources, MSG1 is used to indicate other requested SIs, and requests for other SIs trigger a random access procedure in MSG3 containing the SI request message. When MSG1 is used, the minimum granularity of the request is a single SI message (i.e., a set of SIBs). A single RACH preamble and / or PRACH resource may 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.

[0027] A self-organizing network (SON) can receive information regarding random access to perform various optimizations. When a UE performs random access for on-demand system information, particularly for NR advanced features, the information available to the self-organizing network (SON) is limited. Similarly, the network may not have information regarding random access performed to request positioning-related system information. This results in significant disadvantages for the SON.

[0028] Therefore, it is desirable to resolve the aforementioned disadvantages, problems, or other shortcomings, or at least provide a useful alternative.

[0029] The two-stage contention-based random access (two-stage CBRA) procedure comprises two main stages. Initially, the user equipment (UE) transmits a random access preamble over the physical random access channel (PRACH) and a payload, such as a Media Access Control Protocol Data Unit (MAC PDU), over 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 from the gNB, within a set time window. This network response is referred to as MsgB. If a Common Control Channel Service Data Unit (CCCH SDU) is included in the MsgA payload, the UE performs a contention resolution using the information provided in the MsgB. If the contention resolution identity received in the MsgB matches the first 48 bits of the CCCH SDU transmitted in the MsgA, the contention resolution is considered successful. Alternatively, if a Cell Radio Network Temporary Identifier (C-RNTI) is transmitted in the MsgA payload, the contention resolution is considered successful when the UE receives a Physical Downlink Control Channel (PDCCH) message addressed by the C-RNTI. If the contention resolution is successful, the random access procedure is considered complete. However, MsgB may contain fallback information corresponding to the random access preamble transmitted in MsgA instead of contention resolution information. Upon receipt of the fallback information, the UE transmits Msg3 and performs contention resolution using Msg4, as in a traditional contention-based random access (CBRA) procedure. In this context, the success of contention resolution also signifies the completion of the random access procedure. If contention resolution fails after the fallback, as it does after the transmission of Msg3, the UE retransmits MsgA.If the configured window for monitoring network responses after sending MsgA expires without receiving MsgB containing either race resolution or fallback information, the UE resends MsgA. If the random access procedure is not completed after a configurable number of MsgA transmissions, the UE returns to a 4-stage random access channel (RACH) procedure, which includes sending only the PRACH preamble.

[0030] The Phase 2 contention-free random access (Phase 2 CFRA) procedure involves the gNB allocating dedicated random access preambles and PUSCH resources to the UE for the transmission of the MsgA. Additionally, the gNB may direct RACH opportunities (ROs) for the transmission of the preamble. Initially, the UE transmits the random access preamble on the PRACH and the payload on the PUSCH using contention-free random access resources, including the dedicated preamble, PUSCH resources, and ROs. Subsequently, after the transmission of the MsgA, the UE monitors the network for responses, specifically from the gNB, within an established window. The random access procedure is considered successfully completed when the UE receives a PDCCH addressed to the C-RNTI. Similarly, the procedure is also considered successfully completed when the UE receives fallback information corresponding to the preamble it transmitted. The network has the ability to associate RACH resource sets with features applicable to random access procedures, such as network slicing, (e)RedCap((enhanced) reduced capabilities), SDT, and NR coverage enhancement. A RACH resource set linked to a feature is valid only for random access procedures applicable to that feature. Additionally, a RACH resource set associated with multiple features is valid only for random access procedures that include at least all of these features. The UE selects applicable RACH resource set(s) after uplink carrier selection (NUL or SUL) and BWP selection, and before RA type selection.

[0031] System information handling takes place in a cell broadcast environment where the base station distributes system information (SI). This SI is organized into a collection of Master Information Blocks (MIBs) and System Information Blocks (SIBs). System information is classified into minimum SI and other SI. Minimum SI contains essential information required for initial access and the acquisition of any additional SI. Minimum SI includes MIB and SIB1. Other SI includes all SIBs not included in minimum SI. These SIBs may be broadcast periodically over the Downlink Shared Channel (DL-SCH), broadcast on-demand over the DL-SCH, or transmitted exclusively over the DL-SCH to User Terminals (UEs) in the RRC_CONNECTED state. On-demand SI is broadcast upon request from UEs in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED states. A UE may request on-demand SI from the gNB via msg1 or msg3.

[0032] For UEs in the RRC_IDLE and RRC_INACTIVE states, a request for other SIs 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 contained in MSG3. Conversely, if the requested SI is associated with a subset of PRACH resources, MSG1 is utilized to indicate the requested other SIs. When MSG1 is used, the minimum granularity of the request is a single SI message containing a set of System Information Blocks (SIBs). A single Random Access Channel (RACH) preamble and / or PRACH resource can facilitate requests for multiple SI messages, and the gNB acknowledges such requests in MSG2. When MSG3 is used, the gNB provides acknowledgments in MSG4. System Information Blocks (SIBs) are defined across various 3GPP releases. SIBs defined in 3GPP Release 15 are referred to as R15 SIBs, while SIBs of Release 16 are called R16 SIBs. Similarly, SIBs of Release 17 are known as R17 SIBs, and SIBs of Release 18 are designated as R18 SIBs. R15 SIBs and R16 SIBs are collectively referred to as pre-R17 SIBs. R17 SIBs and R18 SIBs include SIB16, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, SIB25, etc., which provide slicing-related information. SIB17 includes settings for trace reference signals. SIB18 includes settings for non-public networks. SIB19 and SIB25 include satellite auxiliary information for non-terrestrial network (NTN) operations. SIB20, SIB21, and SIB24 assist UEs with multicast and broadcast services (MBSs). SIB22 is for ATG (Air to Ground).SIB23 is for sidelink positioning. The present invention provides a mechanism for managing SI requests while ensuring compatibility with multiple 3GPP releases.

[0033] The 5G NR (New Radio) wireless access network, also known as NG-RAN (Next Generation Radio Network), comprises multiple NR base stations known as gNBs. These gNBs can be interconnected via Xn interfaces and linked to various core network elements such as the AMF (Access and Mobility Management Function) and UPF (User Plane Function). Additionally, gNBs can be separated into two physical entities: the CU (Centralized Unit) and the DU (Distributed Unit). The CU supports the upper 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 to serve numerous UEs (User Equipment).

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

[0035] To address this problem, 3GPP introduced Auto-Configuration Network (SON) techniques to wireless technologies such as NR. SON was first introduced in 3GPP Release 9 for LTE. SON solutions are classified into three types: Self-Configuration, Self-Optimization, and Self-Healing. SON architectures can be centralized, distributed, or hybrid solutions.

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

[0037] A UE requesting on-demand system information can log and record a list of System Information Blocks (SIBs) used and report them to the network in a Random Access (RA) report. The network is notified of 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 within the system information, meaning it can have a maxSIB size. "intendedSIBs-r17" is a SEQUENCE (SIZE (1...maxSIB)) OF SIB-Type-r17 and is OPTIONAL. In the prior art, "intendedSIBs" includes instructions regarding the individual system information types requested. However, considering the size constraints for reporting, the current design allows the UE to report only the 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 the intended SIBs does not allow the UE to inform the network whether it has requested on-demand system information, slicing-related system information, NTN-related system information, MBS-related information, ATG-related information, and sidelink positioning-related information, which degrades the efficiency of the autoconfiguring network.

[0038] In the prior art, the UE does not notify the network of a request for positioning-related system information. "intendedSIBs" do not include positioning system information blocks.

[0039] In the described system, the UE transmits Random Access Channel (RACH) reports to the network via Radio Resource Control (RRC) messages, such as UE Information Response. Upon receiving a RACH report, the gNodeB Central Unit (gNB CU) may forward it to a gNodeB Distributed Unit (gNB DU) or an Operations, Administration, and Maintenance (OAM) Autoconfigurable Network (SON) module. Alternatively, the gNB CU may utilize the report directly 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, contention resolution timers, the number of RACH preambles for two-phase RACH, and parameters related to the Physical Uplink Shared Channel (PUSCH) for two-phase RACH. Detailed descriptions of the various parameters that may be included in a random access report are provided in 3GPP specifications such as TS 38.331.

[0040] A UE can report its mobility history information to the network, including both PCell and PSCell mobility history data. This information is subsequently utilized in handover preparation through handover preparation procedures via NG and XN interfaces. These interfaces provide the target NG-RAN node with a list of previously visited cells and associated cell-specific information elements. Additionally, the handover preparation procedure enables the propagation of collected data by initiating the collection and storage of UE history information by prompting the target NG-RAN node. Detailed specifications for mobility history information are outlined in 3GPP standards such as TS 38331 and TS 38300. An excerpt from TS 38.331 is provided below.

[0041]

[0042] RedCap UEs are designed to have 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 aim for even lower complexity than RedCap UEs and possess significantly reduced capabilities. For eRedCap UEs, it is essential to support reduced downlink / uplink peak data rates of 10 Mbps. This requirement applies regardless of the presence or absence of a reduced baseband bandwidth of 5 MHz for unicast PDSCH and PUSCH in FR1. eRedCap features are designed for UEs with moderate performance requirements. Devices supporting eRedCap optimize networks through reduced complexity, improved power efficiency, and cost-effectiveness. Some of the key features of eRedCap UEs are enhanced bandwidth flexibility, lower power consumption, simplified device capabilities and improved mobility and coverage, and seamless integration with 5G networks.

[0043] Now, with reference to the drawings, particularly FIGS. 1 to 10, in which similar reference characters consistently represent corresponding features throughout the drawings, preferred embodiments are illustrated.

[0044] FIG. 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), memory (105), an I / O interface (107), and a random access reporting control unit (109). Additionally, the processor (103) of the UE (101) communicates with the memory (105), the I / O interface (107), and the random access reporting control unit (109). The processor (103) is configured to execute instructions stored in the memory (105) and perform various processes. The processor (103) may include one or more processors and may be a general-purpose processor such as a central processing unit (CPU) or an application processor (AP), a graphics-only processing unit such as a graphics processing unit (GPU) or a visual processing unit (VPU), and / or an artificial intelligence (AI)-only processor such as a neural processing unit (NPU).

[0045] Additionally, the memory (105) of the UE (101) includes storage locations that can be addressed via the processor (103). The memory (105) is not limited to volatile or non-volatile memory and may include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical disks, floppy disks, flash memory, EPROM, or EEPROM memory may also be included in the memory (105). Additionally, the memory (105) of the UE (101) may store various information received from the network device (405). The UE (101) may store various information such as triggers for random access using eRedCap features, intended SIBs, positioning-related system information, etc.

[0046] 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 network devices. This interface is used to ensure that data is transmitted and received by maintaining seamless communication between the UE (101) and external devices. Additionally, the I / O interface (107) facilitates the integration of the UE (101) with other network components, thereby improving its ability to manage random access information.

[0047] The random access reporting control unit (109) communicates with the I / O interface (107) and memory (105) to manage random access information in a wireless network. The random access reporting control unit (109) is innovative hardware 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.

[0048] The random access report control unit (109) triggers a random access procedure. This procedure includes initiating a series of actions that allow a user terminal (UE) to establish a connection with the network, and typically begins with the transmission of a preamble to a base station. Additionally, the random access report control unit (109) logs information regarding features related to the random access procedure. This logging process includes capturing data such as access time, specific resources utilized, and any anomalies or failures that occurred during the procedure. Features related to the random access procedure may include, but are not limited to, eRedCap, system information, and positioning-related system information. Information regarding these features is important for optimizing the access procedure as it provides insight into the network configuration and the capabilities of the UE. Information regarding features related to random access is included in RA-InformationCommon and is logged in at least one of the random access report (RA-Report), wireless link failure report (RLF report), successful 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 quality of service. Additionally, the random access reporting control unit (109) transmits an RRC signaling message to a network device indicating that the eRedCap feature is part of the combination of features that initiated the random access procedure. This signaling message is important for the network to understand the context of the access attempt and allocate resources accordingly. The RRC signaling message may include, but is not limited to, a UE information response RRC message that provides detailed information about the UE's identity, capabilities, and current status.

[0049] The random access reporting control unit (109) logs information about features associated with the resource for random access by including feature combination information when random access is triggered using feature-specific random access resources associated with eRedCap. This includes recording the specific resource block and time slot assigned to the access attempt, as well as the arbitrary priority level assigned to the eRedCap feature. Additionally, the random access reporting control unit (109) includes eRedCap features in the reported feature combination transmitted for the triggered feature combination. This enables resource management by allowing the network to recognize specific features that affected the access procedure. Furthermore, the random access reporting control unit (109) determines whether the value of the used feature or feature combination differs from the triggered feature combination. This comparison is essential for identifying discrepancies that may indicate potential problems or optimizations in the access process. Additionally, the random access reporting control unit (109) includes the eRedCap feature in the reported feature combination transmitted from the used feature combination when the eRedCap feature is part of the feature combination associated with the random access resource utilized in the random access procedure and the value of the used feature or feature combination is different from the triggered feature combination. This detailed reporting allows the network to dynamically adjust its configuration to ensure that the access procedure remains reliable under various conditions.

[0050] In one embodiment, the system information includes information on whether the UE (101) has requested slicing-related system information, NTN-related system information, multicast and broadcast service (MBS)-related information, Air To Ground (ATG)-related information and sidelink positioning-related information through the on-demand system information.

[0051] Additionally, the random access reporting control unit (109) detects a request for an OSI from a network device. This detection involves monitoring network signals for specific requests indicating the need for a System Information Block (SIB) to be transmitted. Additionally, the random access reporting control unit (109) generates an IE1 containing a first list of requested SIBs. The first list of requested SIBs may include, but is not limited to, SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, and SIB15. These SIBs provide essential information for network configuration, such as cell identity, access restriction, and scheduling information. Additionally, the random access reporting control unit (109) generates an IE2 containing a second list of requested SIBs. The second list of requested SIBs may 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 is used for advanced network operations. SIB16 provides slicing-related information. SIB17 includes settings for tracking reference signals. SIB18 includes settings for non-public networks. SIB19 and SIB25 include satellite auxiliary information for non-terrestrial network (NTN) operations. SIB20, SIB21, and SIB24 assist the UE for MBS. SIB22 is for ATG. SIB23 is for sidelink positioning. This means that the random access control unit informs the network whether the UE has requested slicing-related system information, NTN-related system information, MBS-related information, ATG-related information, and sidelink positioning-related information through on-demand system information, which helps the network optimize each of these features.Additionally, the random access reporting control unit (109) transmits IE1 and IE2 to the network device to request the intended SIB. During transmission, the random access reporting control unit (109) determines whether the requested SIB intended by the UE (101) includes both the SIB prior to R17 and the R17 / R18 SIB. This determination ensures SIB compatibility and the correct interpretation of the SIB by the network. Additionally, if the requested SIB intended by the UE (101) does not include both the SIB prior to R17 and the R17 / R18 SIB, the random access reporting control unit (109) transmits IE1 containing either the SIB prior to R17 having R15 or R16 and IE2 containing either the SIB of R17 or R18. This selective transmission helps manage network resources and avoid unnecessary data transmission. Additionally, the random access report control unit (109) simultaneously transmits the first IE1 and IE2 to the network device when the requested SIB intended by the UE (101) includes both the SIB prior to R17 and the R17 / R18 SIB. This simultaneous transmission ensures that the UE provides information in a timely manner, thereby facilitating smooth network operation.

[0052] The random access reporting control unit (109) transmits IE1 and IE2 using specific enumerated values ​​within the SIB-Type enumeration to report a request for a positioning SIB, distinguishing it from other SIBs reported using individual values. While reporting individual values ​​helps the network obtain detailed information about the exact system information used by the UE, this requires more memory and processing, resulting in significant overhead for the UE. Reporting individual values ​​increases signaling overhead. The increase in memory and signaling overhead can be up to nearly 50 times. To avoid this overhead, the random access reporting control unit (109) transmits only a single enumerated value indicating that a positioning SIB has been requested, instead of notifying that a specific positioning SIB has been requested. This slightly reduces the efficiency of the SON, but considering the reduction in memory and signaling overhead, this may still be acceptable.

[0053] FIG. 2 illustrates a block diagram of a network device for managing random access information in a wireless network according to embodiments disclosed in this specification.

[0054] A network device (201) includes a processor (203), memory (205), an I / O interface (207), and a random access reporting control unit (209). Additionally, the processor (203) of the network device (201) communicates with the memory (205), the I / O interface (207), and the random access reporting control unit (209). The processor (203) is configured to execute instructions stored in the memory (205) and perform various processes. The processor (203) may include one or more processors and may be a general-purpose processor such as a central processing unit (CPU) or an application processor (AP), a graphics-only processing unit such as a graphics processing unit (GPU) or a visual processing unit (VPU), and / or an artificial intelligence (AI)-only processor such as a neural processing unit (NPU).

[0055] Additionally, the memory (205) of the network device (201) includes storage locations that can be addressed via the processor (203). The memory (205) is not limited to volatile or non-volatile memory and may include one or more computer-readable storage media. Non-volatile storage elements such as magnetic hard disks, optical disks, floppy disks, flash memory, EPROM, or EEPROM memory may also be included in the memory (205). Additionally, the memory (205) of the network device (201) may store various information received from the UE (101). The network device (201) may store various information such as triggers for random access using eRedCap features received in RRC signaling messages, intended SIBs, positioning-related system information, etc.

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

[0057] The random access reporting control unit (209) communicates with the I / O interface (207) and memory (205) to manage random access information in a wireless network. The random access reporting control unit (209) is innovative hardware 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.

[0058] The random access reporting control unit (209) receives an RRC signaling message from the UE (101) that indicates information about features related to random access. Features related to random access include eRedCap, system information, and positioning-related system information. The control unit is designed to interpret these features. The control unit utilizes advanced techniques for parsing the RRC signaling message to ensure that information is extracted and processed. eRedCap system information may include parameters such as reduced capability device indicators used to optimize network resource allocation for devices with limited capability and to ensure seamless connectivity.

[0059] The random access reporting control unit (209) receives IE1 and IE2 from the UE (101). The random access reporting control unit (209) identifies a first list of requested system information blocks (SIBs) and a second list of requested SIBs from the first IE1 and the second IE2. Through these information elements (IEs), the random access control unit identifies whether the UE (101) has requested slicing-related system information, NTN-related system information, MBS-related information, ATG-related information, and sidelink positioning-related information through on-demand system information. Additionally, the random access reporting control unit (209) optimizes random access parameters based on the first list of requested SIBs and the second list of requested SIBs. This optimization process includes adjusting parameters such as preamble transmission power, backoff interval, and contention resolution timer to improve the success rate of random access attempts and reduce latency.

[0060] Additionally, if the features related to random access include eRedCap as features that trigger random access or features used for random access, the random access reporting control unit (209) optimizes random access parameters based on the received feature-related random access information. The eRedCap feature is particularly important for devices operating under constrained conditions, such as IoT devices with limited processing power and battery life. By adjusting the random access parameters to accommodate the eRedCap feature, the control unit ensures that such devices can access the network without compromising operational constraints. This may include dynamically adjusting the number of preamble attempts or modifying access blocking parameters to prioritize eRedCap-enabled devices.

[0061] Additionally, when a single enumerated value for positioning system information is received, the random access reporting control unit (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 position, timing advance, and reference signal measurement without significant overhead of signaling and memory. By utilizing this information, the control unit can fine-tune the random access parameters to improve the reliability of the positioning service. This optimization is particularly beneficial for applications requiring precise location tracking, such as emergency services, navigation systems, and location-based services.

[0062] FIG. 3 illustrates a flowchart illustrating a method for managing random access information in a wireless network by a UE according to embodiments disclosed in this specification.

[0063] In block (301), the method includes the step of triggering a random access procedure by the UE (101). This trigger may be initiated based on a request from a higher layer, such as an application or a Non Access Stratum, or for internal operation. The UE may utilize specific techniques to determine the optimal timing for initiating the random access procedure by considering factors such as current network load and past access success rates. Additionally, the UE may store a history of previous random access attempts to fine-tune the triggering criteria over time.

[0064] In block (303), the method includes the step of logging information about features related to random access by the UE (101). Features related to random access may include, but are not limited to, eRedCap features, system information, and positioning-related system information. The logging process includes capturing detailed metadata, such as timestamps, frequency bands, and cell IDs associated with each random access attempt. This information is stored in secure non-volatile memory within the UE to ensure persistence over power cycles. Additionally, the UE may use compression techniques to store large amounts of logged data without exceeding memory constraints.

[0065] In block (305), the method includes the step of transmitting an RRC signaling message containing information regarding random access (from block (303)) to a network device (201) by the UE (101). Information regarding features related to random access is included in at least one of RA-report, RLF-report, SHR, SPR, and CEF-report. The RRC signaling message is formatted according to a predefined protocol that ensures compatibility with various network device configurations. The UE may include additional diagnostic information, such as an error rate or latency metric, to assist the network device in optimizing its response to random access requests.

[0066] FIG. 4 illustrates a flowchart illustrating a method for managing random access information in a wireless network by a network device according to embodiments disclosed in this specification.

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

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

[0069] FIG. 5 illustrates a flowchart illustrating a method for logging and reporting UsedFeatureCombination according to embodiments as disclosed in this specification.

[0070] In block (501), the method includes the step of performing random access using a random access resource associated with eRedCap by a UE (101). The UE (101) selects an appropriate random access resource based on its current location, network status, and specific requirements of eRedCap features. The selection process may include a decision technique that evaluates multiple resource options to identify a resource suitable for the current context. The UE (101) then initiates a random access procedure using the selected resource to ensure compliance with network protocols and standards.

[0071] In block (503), the method includes the step of including eRedCap in the usedFeatureCombination within RA-InformationCommon by the UE (101). This inclusion includes updating the RA-InformationCommon data structure with the relevant eRedCap feature details. The UE (101) may also include additional context-specific data, such as the duration of random access attempts and any anomalies that occurred, to provide a comprehensive view of the used feature combinations. This information is then prepared to be transmitted to a network device as part of a reporting process.

[0072] In block (505), the method includes the step of reporting to the network device (201) at least one of RA reporting, CEF reporting, RLF reporting, and SHR, the information logged for eRedCap within usedFeatureCombination by the UE (101). The reporting process includes formatting the logged information according to the specific requirements of each reporting type while ensuring compatibility with the data processing system of the network device. The UE (101) may also implement an error checking mechanism to verify the completeness of the reported data before transmission. Once prepared, the report is transmitted to the network device using a secure communication channel to prevent data interception or loss.

[0073] FIG. 6 illustrates a flowchart illustrating a method for logging and reporting triggeredFeatureCombination according to embodiments as disclosed in this specification.

[0074] In block (601), the method includes the step of triggering random access by the UE (101) using eRedCap. The triggering process is initiated based on predefined criteria, such as network requirements or specific application requirements, that indicate 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 random access. Once triggered, the UE (101) proceeds with the random access procedure while ensuring compliance with network protocols and standards.

[0075] In block (603), the method includes the step of including eRedCap in the triggeredFeatureCombination within RA-InformationCommon by the UE (101). This inclusion includes updating the RA-InformationCommon data structure with the relevant eRedCap feature details. The UE (101) may also include additional context-specific data, such as the duration of random access attempts and any anomalies that occurred, to provide a comprehensive view of the triggered feature combination. This information is then prepared to be transmitted to a network device as part of a reporting process.

[0076] In block (605), the method includes the step of reporting the logged information for eRedCap within the triggeredFeatureCombination by the UE (101) in at least one of the RA report, CEF report, RFF report, and SHR. The reporting process includes formatting the logged information according to the specific requirements of each report type while ensuring compatibility with the data processing system of the network device. The UE (101) may also implement an error checking mechanism to verify the completeness of the reported data before transmission. Once prepared, the report is transmitted to the network device using a secure communication channel to prevent data interception or loss.

[0077] In one embodiment, when random access is triggered by eRedCap, the UE (101) sets triggeredFeatureCombination to indicate that the random access was triggered by the eRedCap feature. The UE (101) informs the network device (201) that eRedCap is part of the feature combination that triggered the random access. The UE includes eRedCap in the reportedFeatureCombination transmitted for triggeredFeatureCombination.

[0078] In one embodiment, if the value of the feature or feature combination used is different from the triggeredFeatureCombination and eRedCap is part of the FeatureCombination associated with the random access resource used in the random access procedure, the UE (101) includes eRedCap in the reportedFeatureCombination transmitted from the triggeredFeatureCombination.

[0079] In one embodiment, Table 2 below is for TS 38.331.

[0080] ReportedFeatureCombination-r18 ::= SEQUENCE { redCap-r18 ENUMERATED {true} OPTIONAL, smallData-r18 ENUMERATED {true} OPTIONAL, nsag-r18 NSAG-List-r17 OPTIONAL, msg3-Repetitions-r18 ENUMERATED {true} OPTIONAL, triggered-S-NSSAI-List-r18 SEQUENCE (SIZE (1..maxNrofS-NSSAI)) OF S-NSSAI OPTIONAL}1> Where one or more of the features including RedCap and / or slicing and / or SDT and / or MSG3 repetition or eRedCap are applicable to this random access procedure as specified in sub-clause 5.1.1b of TS 38.321[3]: 2> Set triggeredFeatureCombination to represent all features that trigger this random access procedure as follows: 3> If this random access procedure is triggered by RedCap, include redCap; 3> If this random access procedure is triggered by SDT, include smallData; 3> If this random access procedure is triggered by a Msg3 repetition, include msg3-Repetitions; 3> If this random access procedure is triggered by slicing, set nsag to the NSAG ID applied in the random access procedure, and set triggered-S-NSSAI-List to include all S-NSSAIs associated with the slice that triggers the access attempt in the random access procedure; 3> If this random access procedure is triggered by eRedCap, include eRedCap; 2> If the value of the used feature or feature combination differs from triggeredFeatureCombination: 3> Set usedFeatureCombination to represent one or more features of the FeatureCombination associated with the random access resources used in the random access procedure as follows: 4> If RedCap is part of a FeatureCombination, include redCap; 4> If it is part of a FeatureCombination that uses SDT, include smallData; 4> If Msg3 repetitions are part of a FeatureCombination, include msg3-Repetitions; 4> If NSAG(s) are part of a FeatureCombination in which they are used, configure NSAG-List to include the NSAG-ID set for the FeatureCombination in which they are used; 4> If eRedCap is part of a FeatureCombination, include eRedCap;

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

[0082] FIG. 7 illustrates a sequence diagram illustrating reporting information regarding eRedCap, system information, and positioning system information to gNB according to embodiments as disclosed herein. In step (S1), the UE (101) receives a UE information request from the network device (201). The UE information request may include, but is not limited to, connestfailreportreq, ra-reportreq, or rlf-reportreq set to true. connestfailreq is a request to report connection establishment failure information indicating a failure of connection establishment between the UE (101) and the network device (201). Similarly, ra-reportreq is a request to report information related to random access, and rlf-reportreq is a request to report wireless link failure information. In step (S2), in response to receiving the UE information request message, the UE (101) includes information related to eRedCap, system information, and positioning system information for the SON. In step (S3), the UE (101) transmits a UE information response message to the network device (201) that represents information related to the logged information, namely eRedCap, system information, and positioning system information. Additionally, in step (S4), the network device (201) optimizes random access parameters based on the eRedCap related information received from the UE (101).

[0083] FIG. 8 illustrates a flowchart illustrating a method for logging information related to intended system information to RA-InformationCommon according to embodiments as disclosed herein. In block (801), the method includes the step of performing a random access procedure for requesting on-demand system information by a UE (101). In block (803), the method includes the step of including whether the UE (101) has requested at least one of slicing-related system information, NTN-related system information, MBS-related information, ATG-related information, and sidelink positioning-related information through the on-demand system information by including information for a SIB corresponding to a new information element. Additionally, if the UE (101) has requested one or more positioning system information, a single enumerated value posSIB is included. In block (805), the method includes the step of reporting the logged information representing IE1 and IE2 by the UE (101) to the network device (201) in the RA report, CEF report, RLF report, and SHR.

[0084] In one embodiment, a UE (101) that has initiated a random access procedure to request on-demand system information informs the network device (201) of the intended SIB by transmitting one or two information elements (as part of an RA-report, RLF report, SHR, SPR, CEF report, etc.) from RA-InformationCommon to the network device (201) using one of the following embodiments, which represent the system information block to be received as a result of the system information request. In one embodiment, when the UE (101) requests an OSI to receive any of the SIBs such as SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, SIB15, SIB16, SIB17, SIB18, SIB19, and SIB20, the UE (101) transmits a list of these SIBs in one information element IE1 (e.g., intendedSIBs-r17). When the OSI is also requested to receive any of the other SIBs such as SIB21, SIB22, SIB23, SIB24, and SIB25, the UE (101) transmits a list of the corresponding SIBs in another information element IE2 (e.g., intendedSIBs-r18 below). The UE (101) transmits a subset of R16 SIBs and R17 SIBs in one information element (e.g., intendedSIBs-r17), and transmits a subset of R17 SIBs and R18 SIBs in another information element (e.g., intendedSIBs-r18). IE1 is a SEQUENCE that can hold up to maxSIB, which is the maximum number of SIBs that the UE (101) can request in a single SI message. The UE (101) includes only up to maxSIB / 2 elements in IE1, which is stored in RA-InformationCommon and transmitted over the network.

[0085] An exemplary structure based on TS 38.331 is provided in Table 3 below.

[0086]

[0087] In one embodiment, if an OSI is transmitted to request SIB1, it is included in IE2 (e.g., intendedSIBs-r18). In an alternative embodiment, SIB21 is included in intendedSIBs-r17, and if the UE (101) transmits an OSI to request SIB19, the UE (101) does not notify the network device (201) that SIB19 has been requested from RA-InformationCommon. In another alternative, SIB21 is included in intendedSIBs-r17, and if the UE (101) transmits an OSI to request SIB19, it is included in another information element (e.g., intendedSIBs-r18). In one embodiment, if an OSI is transmitted to request SIB1, it is included in IE2 (e.g., intendedSIBs-r18). A gNB (201) (hereinafter, the gNB and network device are used interchangeably) that receives RA-InformationCommon and performs SON based on the received information combines both sequence IE1 and sequence IE2, identifies a list of all requested SIBs, and performs the necessary optimization.

[0088] In one embodiment, when the UE (101) requests an OSI to receive any of the SIBs such as SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, and SIB15, the UE (101) transmits a list of these SIBs in one information element IE1 (e.g., intendedSIBs-r17). When the OSI is also requested to receive any of the other SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, and SIB25, the UE (101) transmits a list of the corresponding SIBs in another information element IE2 (e.g., intendedSIBs-r18 below). The UE (101) transmits an R15 or R16 SIB in one information element (e.g., intendedSIBs-r17) and transmits any R17 SIB and R18 SIB in another information element (e.g., intendedSIBs-r18). If the requested SIB intended by the UE (101) includes both the SIB prior to R17 (R15 or R16 SIB) and the R17 / R18 SIB, both IE1 and IE2 may be reported simultaneously.

[0089] An exemplary structure based on TS 38.331 is provided in Table 4 below.

[0090]

[0091] In one embodiment, when an OSI is transmitted to request SIB1, it is included in IE2 (e.g., intendedSIBs-r18).

[0092] In one embodiment, the UE (101) notifies the network device (201) that an OSI has been transmitted to request positioning system information. The UE (101) may use a specific value within the enumeration of SIB-Type-r18 to indicate this.

[0093] Exemplary specification excerpts are provided in Table 5 below.

[0094]

[0095] The enumeration pos-sib indicates that the UE (101) has requested an SI message to receive a positioning SIB.

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

[0097]

[0098] Here, also, the enumeration pos-sib indicates that the UE (101) has requested an SI message to receive a positioning SIB. The gNB (201), which receives the RA-InformationCommon and performs a SON based on the received information, combines IE1 and IE2, identifies a list of all requested SIBs, and performs the necessary optimizations.

[0099] In one embodiment, the gNB (201) identifies that an OSI has been requested for a positioning SIB based on the presence of SIB-Type-r17 and SIB-Type-r18. If neither SIB-Type-r17 nor SIB-Type-r18 is present, the UE (101) identifies that the requested system information is for a positioning SIB.

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

[0101] IE1 can hold up to maxSIB elements in the SEQUENCE, that is, maxSIB is the maximum number of SIBs that the UE (101) can request in a single SI message. However, the UE (101) includes only up to maxSIB / 2 elements in IE1, which is stored in RA-InformationCommon and transmitted over the network, and includes the remaining elements in IE2.

[0102] In one embodiment, when the UE (101) requests an OSI to receive any of the following SIBs: SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, the UE may transmit a list of these SIBs in one information element IE1 (e.g., intendedSIBs-r17). When the OSI is requested to receive any of the other SIBs such as SIB16, SIB15, SIB16, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, SIB25, the UE (101) transmits a list of the corresponding SIBs in another information element IE2 (e.g., intendedSIBs-r18 below), where IE2 is encoded as a BITSTRING.

[0103] If the OSI includes an NR R15 / R16 SIB, the UE transmits a list of SIB identifiers (e.g., intendedSIBs-r17). If the OSI includes an NR R17, R18, or any SIB defined in a later 3GPP release, the UE (101) transmits a bitstring that identifies the R17 SIB, the R18 SIB, and later versions of the NR.

[0104] An exemplary structure based on TS 38.331 is provided in Table 7 below.

[0105] intendedSIBs-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL,SIB-Type-r17 ::= ENUMERATED {sibType2, sibType3, sibType4, sibType5, sibType9, sibType10-v1610, sibType11-v1610, sibType12-v1610, sibType13-v1610, sibType14-v1610, spare6, spare5, spare4, spare3, spare2, spare1}intendedSIBs-r18 BIT STRING(SIZE(32)) OPTIONAL intendedSIBs This field indicates the SIB that the UE intends to receive as a result of an on-demand SI request initiated by the UE (where an RA procedure is used as the SI request). That is, it indicates one of the SIB(s) within the SI message requested to be broadcast that the UE is interested in. If the UE intends to receive any of SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, or SIB14, the UE transmits intendedSIBs-r17; otherwise, the UE transmits intendedSIBs-r18. The first bit of intendedSIBs-r18 indicates that SIB15 is requested, the second bit indicates that SIB16 is requested, the third bit indicates that SIB17 is requested, the fourth bit indicates that SIB18 is requested, the fifth bit indicates that SIB19 is requested, the sixth bit indicates that SIB20 is requested, the seventh bit indicates that SIB21 is requested, the eighth bit indicates that SIB22 is requested, the ninth bit indicates that SIB23 is requested, the tenth bit indicates that SIB24 is requested, the eleventh bit indicates that SIB25 is requested, and so on.

[0106] In one embodiment, when an OSI is transmitted to request SIB1, it is included in IE2 (e.g., intendedSIBs-r18). IE1 may hold up to maxSIB, which is the maximum number of SIBs that a UE (101) can request in a single SI message. However, the UE (101) includes only maxSIB / 2 elements in IE1, which is stored in RA-InformationCommon and transmitted over the network. A gNB (201) that receives RA-InformationCommon and performs SON based on the received information combines IE1 and IE2, identifies a list of all requested SIBs, and performs necessary optimizations.

[0107] Additionally, in one embodiment, if the UE (101) requests an OSI to receive only one of the following SIBs: SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, SIB14, the UE (101) may transmit a list of these SIBs in one information element IE1 (e.g., intendedSIBs-r17). If the OSI request includes any of the other SIBs such as SIB16, SIB15, SIB17, SIB18, SIB19, SIB20, SIB21, SIB22, SIB23, SIB24, and SIB25, the UE (101) transmits a list of all SIBs (including SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, and SIB14) in another information element IE2 (e.g., intendedSIBs-r18 below), and IE2 is encoded as a BITSTRING.

[0108] If the OSI contains only NR R15 / R16 SIBs, the UE transmits a list of SIB identifiers (e.g., intendedSIBs-r17) or a BITSTRING. If the OSI contains any SIB defined in NR R17, R18, or later 3GPP releases, the UE transmits a BITSTRING that identifies all R17 SIBs, R18 SIBs, and later versions of NR.

[0109] An exemplary structure based on TS 38.331 is provided in Table 8 below.

[0110] intendedSIBs-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL,SIB-Type-r17 ::= ENUMERATED {sibType2, sibType3, sibType4, sibType5, sibType9, sibType10-v1610, sibType11-v1610, sibType12-v1610, sibType13-v1610, sibType14-v1610, spare6, spare5, spare4, spare3, spare2, spare1}intendedSIBs1-r18 BIT STRING(SIZE(32)) OPTIONAL intendedSIBs1 This field indicates the SIB that the UE intends to receive as a result of an on-demand SI request initiated by the UE (where an RA procedure is used as the SI request). That is, it indicates one of the SIB(s) within the SI message requested to be broadcast that the UE is interested in. If the UE intends to receive only one of SIB2, SIB3, SIB4, SIB5, SIB6, SIB9, SIB10, SIB11, SIB12, SIB13, or SIB14, the UE transmits intendedSIBs-r17; otherwise, the UE transmits intendedSIBs-r18. The first bit of intendedSIBs-r18 indicates SIB1, the second bit indicates SIB2, the third bit indicates SIB3, and so on.

[0111] In one embodiment, when OSI is transmitted to request SIB1, it is included in IE2 (e.g., intendedSIBs-r18). In one embodiment, bits 6, 7, and 8 of the BITSTRING are not set to 1. In an alternative embodiment, bit 6 represents SIB9, bit 7 represents SIB10, bit 8 represents SIB11, bit 9 represents SIB12, and so on. When UE (101) transmits intendedSIBs1-r18, UE (101) may not transmit intendedSIBs-r17.

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

[0113] gNB (201), which receives RA-InformationCommon and performs SON based on the received information, combines IE1 and IE2, identifies a list of all requested SIBs, and performs necessary optimizations.

[0114] In one embodiment, the UE (101) reports a list of positioning system information blocks to be received in the RA-InformationCommon while transmitting an on-demand system information request. This may be included in a single information element within the RA-InformationCommon. When the UE (101) reports a positioning system information block in the RA-InformationCommon, the UE (101) will not include other (non-positioning) system information blocks.

[0115] FIG. 9 illustrates a sequence diagram illustrating reporting intendedSIBs to a gNB according to embodiments as disclosed herein. In step (S1), the UE (101) receives a UE information request from a network device (201). The UE information request may include, but is not limited to, a connestfailreportreq, ra-reportreq, or rlf-reportreq set to true. connestfailreq is a connection establishment failure request message indicating a failure of connection establishment between the UE (101) and the network device (201). Similarly, ra-reportreq is a random access request message, and rlf-reportreq is a wireless link failure request message. In step (S2), the UE (101) includes or logs IE1 and IE2 for the intended SIB in RA-InformationCommon. In step (S3), the UE (101) transmits a UE information response to the network device (201) by including RA-InformationCommon. In step (S4), the network device (201) optimizes random access parameters based on information received from the UE (101) in the UE information response message.

[0116] FIG. 10a illustrates a flowchart illustrating a method for handling MHI when a UE unregisters and registers on the same network, according to embodiments as disclosed herein. In block (901), the method includes the step of logging mobility history information (MHI) by the UE (101). In block (903), the method includes the step of unregistering from the network device (201) by the UE (101). In block (905), the method includes the step of retaining or maintaining the logged information regarding the MHI. In block (907), the method includes the step of registering to the same network device (201) by the UE (101). Upon registration, in block (909), the method includes the step of retaining or maintaining the MHI logged by the UE (101) and further updating the visited cells and visited PSCells in the MHI.

[0117] FIG. 10b illustrates a flowchart illustrating a method for handling an MHI when a UE unregisters and registers in different networks, according to embodiments as disclosed in this specification.

[0118] In block (911), the method includes the step of logging mobility history information (MHI) by the UE (101).

[0119] In block (913), the method includes the step of unregistering from the network device (201) by the UE (101).

[0120] In block (915), the method includes the step of holding or maintaining information about the MHI logged by the UE (101).

[0121] In block (917), the method includes the step of registering a different network device (201) by the UE (101).

[0122] When registering, in block (919), the method includes the step of releasing the MHI logged by the UE (101).

[0123] In one embodiment, an NR UE (101) that stores mobility history information (MHI) releases the MHI when registering to a different PLMN, a different SNPN, or a different PNI-NPN. When the UE (101) is registered to the PLMN and then registers to the SNPN, the UE releases the mobility history information. When the UE (101) is registered to the PLMN and then registers to the PNI-NPN, the UE releases the mobility history information. When the UE (101) is registered to the SNPN and then registers to the PLMN, the UE releases the mobility history information. When the UE is registered to the PLMN and then registers to the PNI-NPN, the UE releases the mobility history information. When the UE (101) is registered to the PNI-NPN and then registers to the SNPN, the UE releases the mobility history information. When the UE (101) is registered to the PLMN and then registers to the PLMN, the UE releases the mobility history information.

[0124] For example, consider a UE (101) that has camped on PLMN1. When the UE (101) unregisters from PLMN1, the UE retains the MHI. Also, when the UE (101) registers to SNPN SNPN2, the UE (101) releases the MHI.

[0125] In another example, consider a UE (101) that has camped on SNPN SNPN1. Also, when the UE (101) unregisters from SNPN1, the UE (101) retains the MHI. Also, when the UE (101) registers to a non-SNPN cell within PLMN1, the UE (101) releases the MHI.

[0126] The UE (101) releases the MHI when registering with a new network, whereas it retains the MHI when unregistering from the network. When registering with a different PLMN, SNPN, PNI-NPN, or a different type of network (in the context of the invention, PLMN, SNPN, or PNI-NPN may be considered as a type of network), the UE (101) releases the MHI.

[0127] This can be expressed in TS 38.331 as shown in Table 9 below.

[0128] 5.7.9 Mobility History Information 5.7.9.1 General This procedure specifies how mobility history information, including RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED, is stored by the UE and released by the UE upon registration with a new PLMN, a new SNPN, or a new PNI-NPN. 5.7.9.3 Release of Mobility History Information If the UE supports the storage of mobility history information, the UE must perform the following: 1> When registering to a new network, if saved, discard mobility history information, that is, release the UE variable VarMobilityHistoryReport.

[0129] FIG. 11 illustrates a block diagram illustrating the structure of a UE according to embodiments as disclosed in the present specification. The UE of FIG. 11 may correspond to the UE of FIG. 1.

[0130] As illustrated in FIG. 11, a UE according to one embodiment may include a transceiver (1110), memory (1120), and a processor (e.g., a control unit) (1130). The transceiver (1110), memory (1120), and processor (1130) of the UE may operate according to the 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. Additionally, the processor (1130), transceiver (1110), and memory (1120) may be implemented as a single chip. Furthermore, the processor (1130) may include at least one processor.

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

[0132] Additionally, the transceiver (1110) can receive a signal through a wireless channel and output it to a processor (1130), and transmit the signal output from the processor (1130) through a wireless channel.

[0133] The memory (1120) can store programs and data necessary for the operations of the UE. Additionally, the memory (1120) can store control information or data included in signals acquired by the UE. The memory (1120) may be a read-only memory (ROM), random access memory (RAM), a storage medium such as a hard disk, CD-ROM, and DVD, or a combination of storage media.

[0134] The processor (1130) can control a series of processes to enable the UE to operate as described above. For example, the transceiver (1110) can receive a data signal including a control signal transmitted by a base station, and the processor (1130) can determine the result of receiving the control signal and the data signal transmitted by the base station.

[0135] FIG. 12 illustrates a block diagram illustrating the structure of a base station according to embodiments as disclosed in the present specification. The base station of FIG. 12 may correspond to the network device of FIG. 2.

[0136] As illustrated in FIG. 12, a base station according to one embodiment may include a transceiver (1210), a memory (1220), and a processor (e.g., a control unit) (1230). The transceiver (1210), memory (1220), and processor (1230) of the base station may operate according to the 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. Additionally, the processor (1230), transceiver (1210), and memory (1220) may be implemented as a single chip. Furthermore, the processor (1230) may include at least one processor.

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

[0138] Additionally, the transceiver (1210) can receive a signal through a wireless channel and output it to a processor (1230), and transmit the signal output from the processor (1230) through a wireless channel.

[0139] The memory (1220) can store programs and data necessary for the operations of the base station. Additionally, the memory (1220) can store control information or data included in signals acquired by the base station. The memory (1220) may be a storage medium such as a read-only memory (ROM), random access memory (RAM), hard disk, CD-ROM, and DVD, or a combination of storage media.

[0140] The processor (1230) can control a series of processes to enable the base station to operate as described above. For example, the transceiver (1210) can receive a data signal including a control signal transmitted by a terminal, and the processor (1230) can determine the result of receiving the control signal and the data signal transmitted by the terminal.

[0141] The foregoing description of specific embodiments will fully reveal the general characteristics of the embodiments in this specification, and thus allow others to easily modify and / or adapt these specific embodiments for various applications without departing from the general concept. Accordingly, such adaptations and modifications are intended to be understood within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that phrases or terms used in this specification are for illustrative purposes only and are not intended to be limiting. Accordingly, although the embodiments in this specification have been described in terms of preferred embodiments, a person skilled in the art will recognize that the embodiments in this specification may be practiced with modifications within the scope of the embodiments as described in this specification.

Claims

Claim 1 A terminal (user equipment, UE) in a wireless communication system comprises: a transceiver; and a controller coupled to said transceiver, wherein the controller is configured to perform a random-access procedure and transmit a message containing random-access information to a base station, wherein the random-access information includes first information for indicating at least one feature that triggers said random-access procedure and second information for indicating at least one feature associated with used random-access resources, and wherein, when said random-access procedure is triggered by a feature of eRedCap (enhanced reduced capabilities), said first information includes an indicator of eRedCap. Claim 2 A terminal according to claim 1, wherein the value of the second information is different from the first information and the feature of the eRedCap is associated with a random access resource used in the random access procedure, the second information includes an indicator of the eRedCap. Claim 3 In claim 1, the controller is further configured to identify that the features of the eRedCap are applicable to the random access procedure, and the terminal is a terminal having an eRedCap. Claim 4 A terminal according to claim 1, wherein the message is a UE information response message, the first information is triggeredFeatureCombination information, and the second information is usedFeatureCombination information. Claim 5 A terminal according to claim 1, wherein the random access information comprises at least one of a third information representing a first SIB (system information block) that the terminal intends to receive or a fourth information representing a second SIB that the terminal intends to receive. Claim 6 In paragraph 5, the purpose of the random access procedure is to request on-demand system information, a terminal. Claim 7 A terminal according to claim 5, wherein the first SIB comprises at least one of SIB type 2, SIB type 3, SIB type 4, SIB type 5, SIB type 9, SIB type 10, SIB type 11, SIB type 12, SIB type 13, SIB type 14, or a positioning SIB, and the second SIB comprises at least one of SIB type 15, SIB type 16, SIB type 17, SIB type 18, SIB type 19, SIB type 20, SIB type 21, SIB type 22, SIB type 23, SIB type 24, or SIB type 25. Claim 8 A method performed by a terminal (user equipment, UE) in a wireless communication system, comprising: performing a random-access procedure; and transmitting a message containing random-access information to a base station, 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 the random-access resources used, and wherein, if the random-access procedure is triggered by a feature of eRedCap (enhanced reduced capabilities), the first information includes an indicator of eRedCap. Claim 9 A method according to claim 8, wherein the value of the second information is different from the first information and the feature of the eRedCap is associated with a random access resource used in the random access procedure, the second information includes an indicator of the eRedCap. Claim 10 A method according to claim 8, further comprising the step of identifying that the features of the eRedCap are applicable to the random access procedure, wherein the terminal is a terminal having an eRedCap. Claim 11 In claim 8, the above message is a UE information response message, the above first information is triggeredFeatureCombination information, and the above second information is usedFeatureCombination information. Claim 12 A method according to claim 8, wherein the random access information comprises at least one of third information representing a first SIB (system information block) that the terminal intends to receive or fourth information representing a second SIB that the terminal intends to receive. Claim 13 In paragraph 12, the purpose of the random access procedure is to request on-demand system information. Claim 14 A method according to claim 12, wherein the first SIB comprises at least one of SIB type 2, SIB type 3, SIB type 4, SIB type 5, SIB type 9, SIB type 10, SIB type 11, SIB type 12, SIB type 13, SIB type 14, or a positioning SIB, and the second SIB comprises at least one of SIB type 15, SIB type 16, SIB type 17, SIB type 18, SIB type 19, SIB type 20, SIB type 21, SIB type 22, SIB type 23, SIB type 24, or SIB type 25.

Images