Wireless communication method and device and computer readable storage medium

Abstract

The invention discloses a wireless communication method and device and a computer readable storage medium. The method comprises: transmitting a message indicating the availability of at least one measurement report to a wireless communication node; receiving, from the wireless communication node, a message requesting the at least one measurement report; the at least one measurement report is sent to the wireless communication node, and the at least one measurement report comprises at least one of the following items: information indicating that a random access channel (RACH) type is two-step random access or four-step random access; the number of preambles transmitted in the RACH process; a beam index list of beams tried in the RACH process; the wave beam type of each wave beam is tried in the RACH process; and a fallback indication indicating whether fallback occurs.

Description

[0001] This application is a divisional application of Chinese patent application No. 201980099264.8, filed on August 14, 2019, entitled "System and method for performing and reporting measurements in a wireless communication network". Technical Field

[0002] This disclosure generally relates to wireless communications, and more specifically, to systems and methods for configuring self-organizing networks. Background Technology

[0003] Self-organizing network technology requires automatic configuration of network elements when deployed to a network environment. Network elements such as user devices and nodes can be configured in real time based on current network conditions. Summary of the Invention

[0004] The exemplary embodiments disclosed herein are intended to address problems related to one or more difficulties presented in the prior art, and provide additional features that will become apparent when taken in conjunction with the accompanying drawings and the following detailed description. Exemplary systems, methods, apparatuses, and computer program products are disclosed herein according to various embodiments. However, it should be understood that these embodiments are presented by way of example and not as limiting, and that various modifications may be made to the disclosed embodiments while remaining within the scope of this disclosure, as will be apparent to those skilled in the art who have read this disclosure.

[0005] In one embodiment, the method performed by a first wireless communication node includes determining at least one parameter associated with a wireless communication device in a wireless communication network. The method further includes comparing the at least one parameter with at least one threshold. The method also includes reporting the at least one parameter to a second wireless communication node associated with the wireless communication network based on the comparison result.

[0006] In another embodiment, the method performed by a wireless communication device includes transmitting a message to a wireless communication node indicating the availability of at least one measurement report. The method also includes receiving a message from the wireless communication node requesting at least one measurement report. The method further includes measuring at least one parameter based on the at least one measurement report. The method also includes generating the at least one measurement report based on the measured at least one parameter. The method further includes transmitting the at least one measurement report to the wireless communication node.

[0007] The above and other aspects and their embodiments will be described in more detail in the drawings, specification and claims. Attached Figure Description

[0008] Various exemplary embodiments of this solution are described in detail below with reference to the accompanying drawings. The drawings are provided for illustrative purposes only and depict only exemplary embodiments of the solution to aid the reader's understanding. Therefore, the drawings should not be construed as limiting the breadth, scope, or applicability of this solution. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of explanation.

[0009] Figure 1 An example cellular communication network is shown that can implement the techniques and other aspects disclosed herein, according to embodiments of the present disclosure.

[0010] Figure 2 Block diagrams of example base stations and user equipment according to some embodiments of the present disclosure are shown.

[0011] Figure 3 A schematic diagram of downlink packet transmission from a node to a user equipment is shown according to some embodiments of the present disclosure.

[0012] Figure 4 Example timing diagrams depicting the duration of inactivity for various user devices according to some embodiments of the present disclosure are shown.

[0013] Figure 5 Example state diagrams representing state transitions and state machines of user equipment in a wireless communication network according to some embodiments of the present disclosure are shown.

[0014] Figure 6 A schematic diagram illustrating message exchange between user equipment and nodes to facilitate the transmission of measurement reports, according to some embodiments of the present disclosure. Detailed Implementation

[0015] Various exemplary embodiments of this solution are described below with reference to the accompanying drawings to enable those skilled in the art to manufacture and use this solution. It will be apparent to those skilled in the art that various changes or modifications can be made to the examples described herein without departing from the scope of this solution after reading this disclosure. Therefore, this solution is not limited to the exemplary embodiments and applications described and illustrated herein. Furthermore, the specific order or hierarchy of steps in the methods disclosed herein is merely an example method. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes can be rearranged while remaining within the scope of this solution disclosure. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in a sample order, and unless otherwise expressly stated, this solution is not limited to the specific order or hierarchy presented.

[0016] Figure 1An example wireless communication network and / or system 100 according to an embodiment of this disclosure is illustrated, in which the techniques disclosed herein can be implemented. In the following discussion, wireless communication network 100 can be any wireless network, such as a cellular network or a narrowband Internet of Things (NB-IoT) network, and is referred to herein as "network 100". Such an example network 100 includes a base station 102 (hereinafter referred to as "BS 102") and user equipment 104 (hereinafter referred to as "UE 104"), which can communicate with each other via a communication link 110 (e.g., a wireless communication channel), and cell clusters 126, 130, 132, 134, 136, 138, and 140 covering a geographic area 101. Figure 1 In this context, BS 102 and UE 104 are contained within the corresponding geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station operating on its allocated bandwidth to provide sufficient radio coverage to its intended users.

[0017] For example, BS 102 can operate within the allocated channel transmission bandwidth to provide sufficient coverage to UE 104. BS 102 and UE 104 can communicate via downlink radio frame 118 and uplink radio frame 124, respectively. Each radio frame 118 / 124 can be further divided into subframes 120 / 127, which may include data symbols 122 / 128. In this disclosure, BS 102 and UE 104 are described herein as non-limiting examples of "communication nodes" that can generally implement the methods disclosed herein. According to various embodiments of this solution, such communication nodes are capable of wireless and / or wired communication.

[0018] Figure 2 A block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., Orthogonal Frequency Division Multiplexing (OFDM) / Orthogonal Frequency Division Multiple Access (OFDMA) signals) according to some embodiments of this solution is shown. System 200 may include components and elements configured to support known or conventional operating characteristics that do not need to be described in detail herein. In one illustrative embodiment, as described above, system 200 may be used in applications such as... Figure 1 In the wireless communication environment 100, data symbols are transmitted (e.g., sent and received).

[0019] System 200 typically includes a base station 202 (hereinafter referred to as "BS 202") and a user equipment 204 (hereinafter referred to as "UE 204"). BS 202 includes a BS (Base Station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected with each other as needed via a data communication bus 220. UE 204 includes a UE (User Equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected with each other as needed via a data communication bus 240. BS 202 communicates with UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for data transmission as described herein.

[0020] As will be understood by those skilled in the art, system 200 may also include, in addition to Figure 2 Any number of modules other than those shown. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in conjunction with the embodiments disclosed herein can be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are typically described according to their functionality. Whether such functionality is implemented in hardware, firmware, or software depends on the specific application and design constraints imposed on the system as a whole. Those skilled in the art can implement such functionality appropriately for each specific application; however, such implementation decisions should not be construed as limiting the scope of this disclosure.

[0021] According to some embodiments, UE transceiver 230 may be referred to herein as "uplink" transceiver 230, which includes a radio frequency (RF) transmitter and an RF receiver, each RF transmitter and receiver including circuitry coupled to antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-duplex manner. Similarly, according to some embodiments, BS transceiver 210 may be referred to herein as "downlink" transceiver 210, which includes an RF transmitter and an RF receiver, each RF transmitter and receiver including circuitry coupled to antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to downlink antenna 212 in a time-duplex manner. The operation of the two transceiver modules 210 and 230 can be coordinated in time such that the uplink receiver circuitry is coupled to the uplink antenna 232 to receive transmissions via wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. In some embodiments, there is tight time synchronization with minimal protection time between changes in duplex direction.

[0022] UE transceiver 230 and base transceiver 210 are configured to communicate via wireless data communication link 250 and cooperate with RF antenna arrangements 212 / 232 appropriately configured to support specific wireless communication protocols and modulation schemes. In some illustrative embodiments, UE transceiver 210 and base transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be understood that this disclosure is not necessarily limited in application to specific standards and related protocols. Rather, UE transceiver 230 and base transceiver 210 may be configured to support alternative or add-on wireless data communication protocols, including future standards or variations thereof.

[0023] According to various embodiments, BS 202 may be an evolved Node B (eNB), a serving eNB, a target eNB, a femtocell, or a picocell. In some embodiments, UE 204 may be embodied in various types of user equipment, such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptops, wearable computing devices, etc. Processor modules 214 and 236 may be implemented or realized using general-purpose processors, content-addressable memory, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), any suitable programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof, intended to perform the functions described herein. In this way, the processor may be implemented as a microprocessor, a controller, a microcontroller, a state machine, etc. The processor may also be implemented as a combination of computing devices, such as a combination of a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other such configuration.

[0024] Furthermore, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be directly embodied in hardware, firmware, software modules executed by processor modules 214 and 236 respectively, or in any practical combination thereof. Memory modules 216 and 234 may be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 may be coupled to processor modules 210 and 230 respectively, such that processor modules 210 and 230 may read information from and write information to memory modules 216 and 234 respectively. Memory modules 216 and 234 may also be integrated into the respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache for storing temporary variables or other intermediate information during the execution of instructions to be executed by processor modules 210 and 230 respectively. Memory modules 216 and 234 may each include non-volatile memory for storing instructions to be executed by processor modules 210 and 230, respectively.

[0025] Network communication module 218 typically refers to the hardware, software, firmware, processing logic, and / or other components of base station 202 that enable bidirectional communication between base station transceiver 210 and other network components and communication nodes configured to communicate with base station 202. For example, network communication module 218 may be configured to support Internet or WiMAX traffic. In a typical deployment, without limitations, network communication module 218 provides an 802.3 Ethernet interface, allowing base station transceiver 210 to communicate with conventional Ethernet-based computer networks. In this way, network communication module 218 may include a physical interface for connecting to a computer network (e.g., a Mobile Switching Center (MSC)). The terms “configured for,” “configured to,” and their conjunctions, as used herein with respect to a specified operation or function, refer to devices, components, circuits, structures, machines, signals, etc., that are physically constructed, programmed, formatted, and / or arranged to perform the specified operation or function.

[0026] After discussing various aspects of the network environment and the devices that can be used to implement the systems, methods, and apparatuses described herein, additional details should be followed.

[0027] Self-organizing networks (SONs) can be categorized into three types: self-configuration, self-optimization, and self-healing. SON functions can include load balancing, coverage and capacity optimization, energy saving, and random access channel (RACH) optimization. These functions can be based on a large amount of collected measurement results, such as information reports from the UE side and performance-related measurements collected and derived from the network side. In some cases, SON has already been applied in LTE-type networks. However, some measurements in LTE-type networks may need to be modified so that SON can be adapted to implementations in New Radio (NR) or 5G-type networks. Adaptability may also include performing new measurements that aid in Operations, Administration, and Maintenance (OAM) to optimize network configuration and perform effective mobility management. These measurements can be collected by the UE or by the network.

[0028] I. Measurements performed via networks This part of the discussion focuses on measurements performed by the network, regardless of whether the UE reports any measurements performed at the UE. As an example, a node (such as a base station) can measure one or more parameters related to the wireless communication network. The node can compare the values ​​of one or more measured parameters to thresholds. Based on the comparison, the node can report the measured parameter values ​​to a second network node, such as the core network (CN), tracking collection entity (TEC), etc. Measured parameters may include, but are not limited to: the radio access network (RAN) portion of downlink delay, the number of UEs in RRC connected state, the number of UEs in RRC inactive state, the average duration of UEs remaining in inactive state, the number of UEs remaining in RRC_INACTIVE state for a duration less than or equal to certain thresholds (wherein these thresholds may be configured by the base station, core network, or predefined in the protocol), the number of state transitions during each granularity period, the number of UE on-demand system information requests, the dedicated preamble for beam fault recovery, and the number of preambles transmitted per cell. The node can compare one or more values ​​of the measured parameters and send these values ​​to a second network node in the wireless communication network. In some embodiments, a node may determine (e.g., select, calculate, identify, etc.) parameter values ​​during a granular period in each RAN based on a notification area. In some embodiments, a node may determine parameter values ​​during a granular period in each cell of the wireless communication network. A granular period may refer to a time period during which measurements of one or more parameters are performed. The granular period may be predefined in a specification, or configured and provided to the UE by the BS or OAM, or configured and notified to the BS by the core network (CN). In some examples, the granular period may be configured and provided to the CN by the BS or OAM.

[0029] In some embodiments, if the measured value of a parameter is greater than a threshold, the node may report the value to a second network node (e.g., a management server, a CN, etc.). In some embodiments, if the measured value of a parameter is greater than or equal to a threshold, the node may report the value to a second network node. In some embodiments, if the measured value of a parameter is less than a threshold, the node may report the value to a second network node. In some embodiments, if the measured value of a parameter is less than or equal to a threshold, the node may report the value to a second network node.

[0030] In some embodiments, a node may periodically report measured parameters to a second network node. In some embodiments, the reporting period may be specified in the specification. In some examples, the reporting period may be configured from the second network node (e.g., a CN) to the first network node (e.g., a gNB / eNB). In some examples, the reporting period is configured by the first network node and provided from the first network node to the second network node.

[0031] Downlink delay in the Radio Access Network (RAN) portion Figure 3 This diagram illustrates the downlink data packet transmission from the node to the user equipment. Specifically, Figure 3 This diagram illustrates the transmission of data packet 300 during the downlink (DL) from node 302 to user equipment 304. The transmission of data packet 300 is described with reference to the RAN protocol architecture, including the Serving Data Application Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical Layer (PHY). The total data packet delay during the DL within the wireless communication network can constitute the delay in the RAN and the delay in the core network (CN). The delay in the RAN... Figure 3 The delay t1 is described as the difference between time T2 and T1. This difference can include the average delay during DL air interference plus RLC delay, the average delay of the DL in the CU-UP (user plane of the central unit) (optional in the case of CU-DU splitting), and the average delay on the F1 user plane interface (F1-U) (optional in the case of CU-DU splitting). It supports splitting the 5G radio access network architecture into a central unit (CU) and distributed units (DU) to support a more flexible transport network and provide an enhanced user experience.

[0032] In one example, the reference point for a data packet arriving at the UE could be the PDCP upper-layer serving access point (SAP), while the reference point for successful reception of the data packet at the UE could be the MAC lower-layer SAP. However, in some other examples, since the RAN portion of the uplink (UL) delay is calculated as the difference between T2' and T1, the DL delay measurement can also include the PDCP reordering portion on the UE side. That is, the DL delay measurement can also include the time period t2. Therefore, the RAN portion of the delay can be equal to T2'–T1. In some embodiments, this difference can be determined based on (e.g., selection, calculation, identification, etc.): the sum of the time for receiving the last portion of an RLC Service Data Unit (SDU) data packet and the time for all previous RLC SDU data packets to be successfully received according to the status report, minus the time the last portion of the same data packet was transmitted in the air divided by the total number of RLC SDUs arriving at the MAC lower-layer SAP. In cases where RLC SDUs will be retransmitted (e.g., for acknowledgment mode), the delay will still only include one contribution to the measurement. In some embodiments, a separate counter can be maintained for each mapped 5G QoS Indicator (5QI) (or QoS Class Identifier (QCI)). In some examples, the base station or node can measure the RAN portion of the DL delay for each data radio bearer (DRB). In some embodiments, the UE can report the PDCP reordering delay on the UE side to the base station or node.

[0033] Number of UEs in RRC_CONNECTED state In some examples, a node can measure the number of UEs in the RRC_CONNECTED state as a parameter. Within a wireless communication network, wireless communication devices (e.g., UEs) can be in different states based on different levels of service activity. These states can include, for example, RRC_INACTIVE, RRC_IDLE, and RRC_CONNECTED. In the RRC_CONNECTED state, an RRC context is established, and all parameters required for communication between the device and the RAN are known to both the device and the node. A node can measure the number of UEs in the RRC_CONNECTED state during a granularity period. In some examples, a node can determine (e.g., select, calculate, identify, etc.) the maximum number of UEs in the RRC_CONNECTED state. In some examples, a node can determine the average number of UEs in the RRC_CONNECTED state during a granularity period. A node can compare the maximum or average number of UEs in the RRC_CONNECTED state to a threshold.

[0034] In some examples, a node may report information to a second network node when the maximum number of UEs in the RRC_CONNECTED state is greater than or equal to a threshold. In some examples, a node may report information to a second network node when the maximum number of UEs in the RRC_CONNECTED state is less than or equal to a threshold. In some examples, a node may report information to a second network node when the average number of UEs in the RRC_CONNECTED state is greater than or equal to a threshold. In some examples, a node may report information to a second network node when the average number of UEs in the RRC_CONNECTED state is less than or equal to a threshold.

[0035] In some examples, a threshold can be determined in several ways, either by comparing it to the maximum number of UEs in the RRC_CONNECTED state or by comparing it to the average number of UEs in the RRC_CONNECTED state. For example, the threshold can be specified in the specification, such as NR, and can be configured from a second network node (e.g., CN) to a first network node (e.g., gNB / eNB), or the threshold can be configured by the first network node (e.g., gNB / eNB) and provided from the first network node to the second network node.

[0036] Based on the comparison between the measured values ​​and the corresponding thresholds, the node can report information to the second network node. This information may include the maximum and / or average number of UEs in the RRC_CONNECTED state, time information associated with when the measurement results were collected, and a corresponding identifier for the measurement granularity (e.g., the physical cell ID for each cell measurement).

[0037] In some examples, a node can determine the average number of UEs in the RRC_CONNECTED state during each granularity period in each cell of the wireless communication network. The node can sample the UE state at predefined intervals, determine the number of UEs in the RRC_CONNECTED state for each cell, and then determine the arithmetic mean of the number across all cells. Similarly, a node can determine the maximum number of UEs in the RRC_CONNECTED state by determining the maximum number across all cells. In some examples, the predefined interval can refer to the sampling period within the granularity period. For example, the sampling interval can refer to a time period after which the value of the parameter is measured. Sampling can be repeated several times in time at sampling periods. The sampling period can be shorter than the granularity period.

[0038] In some examples, a node can determine (e.g., select, calculate, identify, etc.) the maximum and average values ​​in contexts other than the individual cell measurements discussed above. For example, a node can determine the average and maximum values ​​based on network slices, where a network slice is a logical network serving a specific service or customer need. In some such examples, a node can determine the maximum and average values ​​based on values ​​determined across multiple network slices. In some other examples, a node can determine the maximum and average values ​​across multiple Public Land Mobile Networks (PLMNs). In some other examples, a node can measure the maximum and average values ​​based on Non-Public Network (NPN) IDs. For example, a node can determine the number of UEs in the RRC_CONNECTED state for each NPN, which can be identified by one or more of the NPN ID, CAG ID (where CAG indicates a closed access group), or PLMN ID. In some embodiments, a node can determine the average and maximum values ​​over various combinations of contexts. For example, a node can determine the average and maximum values ​​based on values ​​determined in each slice of each PLMN, or in each cell of each PLMN, or for each slice in each cell, or for each NPN ID in each PLMN.

[0039] In some embodiments, a predefined interval (after which the node samples the UE's state) and granularity period can be specified in the specification. In some examples, the predefined interval and granularity period can be configured from the CN to the gNB / eNB. In some examples, the predefined interval and granularity period are provided from the gNB / eNB to the CN (e.g., the predefined interval and granularity period can be determined by the gNB / eNB or a second network node).

[0040] Number of UEs in RRC_INACTIVE state In this example, the node can measure the average and maximum number of UEs in the RRC_INACTIVE state. In the communication network, when an RRC connection is suspended (e.g., by receiving an RRC release message with a suspension indication from the network), the UE can store its inactive access stratum (AS) context and any configuration information received from the network, and can transition to the RRC_INACTIVE state. In the RRC_INACTIVE state, the RAN can configure a RAN-based notification area for the UE, and the UE can perform RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area. In some examples, the last serving eNB can maintain the UE context and the NG connections associated with the UE with the Serving Access and Mobility Management Function (AMF) and User Plane Function (UPF). In some examples, the UE context may be reallocated or released.

[0041] A node can measure the number of UEs in the RRC_INACTIVE state during each granularity period. Similar to the discussion above regarding determining the number of UEs in the RRC_CONNECTED state, a node can determine a maximum or average number of UEs in the RRC_INACTIVE state. In some examples, when the maximum number of UEs in the RRC_INACTIVE state is determined to be greater than or equal to a threshold, the node can report this information to a second network node. In some examples, when the maximum number of UEs in the RRC_INACTIVE state is determined to be less than or equal to a threshold, the node can report this information to a second network node. In some examples, when the average number of UEs in the RRC_INACTIVE state is determined to be greater than or equal to a threshold, the node can report this information to a second network node. In some examples, when the average number of UEs in the RRC_INACTIVE state is determined to be less than or equal to a threshold, the node can report this information to a second network node.

[0042] In some examples, the threshold for comparison with the maximum number of UEs in RRC_INACTIVE or the threshold for comparison with the average number of UEs in RRC_INACTIVE can be determined in several ways. For example, the threshold can be specified in the specification, such as NR, and the threshold can be configured from a second network node (e.g., CN, TEC, etc.) to a first network node (e.g., gNB / eNB), or the threshold can be provided from the first network node to the second network node (e.g., a predetermined interval is determined by the gNB / eNB or the second network node).

[0043] Based on the comparison between the measured values ​​and the corresponding thresholds, the node can report information to the second network node. This information may include the maximum and / or average number of UEs in the RRC_INACTIVE state, the time information associated with when the measurement results were collected, and the corresponding identifier for the measurement granularity (e.g., the physical cell ID used for each cell measurement).

[0044] In some examples, a node can perform measurements in several ways. For instance, in one approach, the node can perform measurements for each RAN-based notification area, while in another, the node can perform measurements for each cell. Regarding the measurements performed for each RAN-based notification area, the node can determine the average number of UEs in the RRC_INACTIVE state during each granularity period of each RAN-based notification area. The node can sample the state of UEs in each RAN-based notification area at predefined intervals and determine the average across the RAN-based notification areas. The node can also determine the maximum number of UEs in the RRC_INACTIVE state during each granularity period of each RAN-based notification area. The node can determine the number of UEs in the RRC_INACTIVE state during each granularity period of each RAN-based notification area and then use the maximum value from all RAN-based notification areas.

[0045] Regarding the measurements performed for each cell, after an RRC connection is suspended, the UE may no longer be connected to the cell. However, the last serving cell will still store the UE context. Therefore, an alternative method for performing measurements for each cell is to assume that a UE in the RRC_INACTIVE state belongs to the last serving cell. Alternatively, in another alternative, an inactive UE is considered to "belong" to the cell in which the UE was released from the RRC_CONNECTED state to the RRC_INACTIVE state. Or, in yet another example, a UE in the RRC_INACTIVE state is considered to "belong" to the cell in which its context is stored. The average number of UEs in the RRC_INACTIVE state provides the average number of UEs in the RRC_INACTIVE state during each granularity period for each cell. Nodes can sample the number of users in the RRC_INACTIVE state for each cell at predefined intervals, where UEs in the RRC_INACTIVE state are considered to belong to the last serving cell. Nodes can then determine the average number of UEs in the RRC_INACTIVE state across all cells.

[0046] The maximum number of UEs in the RRC_INACTIVE state provides the maximum number of UEs in the RRC_INACTIVE state for each granularity period in each cell. Similar to determining an average, a node can determine the maximum value by selecting the maximum number of UEs in the RRC_INACTIVE state across cells. In some examples, a node can also determine the percentage of UEs in the RRC_INACTIVE state within a cell for each granularity period. The node can determine this percentage based on the ratio of the average number of UEs in the RRC_INACTIVE state to the sum of the average number of UEs in the RRC_INACTIVE state and the average number of UEs in the RRC_CONNECTED state.

[0047] In some examples, a node can determine maximum and average values ​​at a granularity beyond the measurements for each cell described above. For example, a node can determine average and maximum values ​​based on network slices, where a network slice is a logical network serving a specific service or customer need. In some such examples, a node can determine maximum and average values ​​based on values ​​determined across multiple network slices. In some other examples, a node can determine maximum and average values ​​across multiple Public Land Mobile Networks (PLMNs). In some other examples, a node can measure maximum and average values ​​based on Non-Public Network (NPN) IDs. For example, a node can determine the number of UEs in the RRC_INACTIVE state for each NPN, which can be identified by one or more of the NPN ID, CAG ID (where CAG indicates a closed access group), or PLMN ID. In some embodiments, a node can determine average and maximum values ​​over various combinations of context. For example, a node can determine average and maximum values ​​based on values ​​determined in each slice of each PLMN, or in each cell of each PLMN, or for each slice in each cell, or for each NPN ID in each PLMN, for each cell in each RAN notification area, or for each RAN notification area in each PLMN.

[0048] In some embodiments, a predefined interval and measurement period can be specified in the network (e.g., NR) specification during which a node samples the state of a UE. In some examples, the predefined interval and granularity period can be configured from a second network node (e.g., CN) to a first network node (e.g., gNB / eNB). In some examples, the predefined interval and granularity period are configured by the first network node and provided from the first network node to the second network node (e.g., the predefined interval and granularity period can be determined by the gNB / eNB or the second network node).

[0049] Average duration of UE in inactive state In some examples, the parameters measured by the node may include the average duration of the UE in an inactive state. This measurement can provide the average duration the UE remains in the RRC_INACTIVE state during each granular period in each cell or each RAN-based notification area. Figure 4 An example timing diagram 400 depicting the durations of various UEs remaining in an inactive state is shown. Specifically, timing diagram 400 includes a first duration 402 associated with a first UE (UE1), a second duration 404 associated with a second UE (UE2), a third duration 406 associated with a third UE (UE3), a fourth duration 408 associated with a fourth UE (UE4), a fifth duration 410 associated with a fifth UE (UE5), and a sixth duration 412 associated with a sixth UE (UE6). UE1 enters the RRC_INACTIVE state at time t1 and leaves the RRC_INACTIVE state at time t1'. UE2 enters the RRC_INACTIVE state at time t2 and leaves the RRC_INACTIVE state at time t2'. UE3 enters the RRC_INACTIVE state at time t3 and leaves the RRC_INACTIVE state at time t3'. UE4 enters the RRC_INACTIVE state at time t4 and leaves the RRC_INACTIVE state at time t4'. UE5 enters the RRC_INACTIVE state at time t5 and leaves the RRC_INACTIVE state at time t5'. UE6 enters the RRC_INACTIVE state at time t6 and leaves the RRC_INACTIVE state at time t6'. The time period T1 to T2 can indicate the observed time period. It should be understood that... Figure 4 The moments described are merely examples and may vary depending on the implementation method.

[0050] Based on the times when a UE enters and leaves its corresponding RRC_INACTIVE state, a node can determine the average amount of time a UE remains in the RRC_INACTIVE state. In one approach, the node can determine the average by dividing the sum of the durations for which those UEs that left the RRC_INACTIVE state during the observation period remained in the RRC_INACTIVE state by the total number of UEs that left the RRC_INACTIVE state during the observation period. Figure 4 It can be seen that UE1, UE2, UE4, and UE5 are the UEs that left their respective RRC_INACTIVE states during the observation time (T1 to T2). Therefore, the average time can be equal to ((t1'-t1)+(t2'-t2)+(t4'-t4)+(t5'-t5)) / 4.

[0051] In another method, a node can determine the average amount of time a UE stays in the RRC_INACTIVE state by dividing the sum of the durations for which those UEs that both entered and left the RRC_INACTIVE state during the observation period remained in the RRC_INACTIVE state by the total number of UEs that both entered and left their respective RRC_INACTIVE states during the observation period. For example... Figure 4 As shown, UE2, UE4, and UE5 are the only UEs that both enter and leave the corresponding RRC_INACTIVE state during the observation period (T1 to T2). Therefore, the average time can be equal to ((t2'-t2)+(t4'-t4)+(t5'-t5)) / 3.

[0052] In another approach, a node can determine the average amount of time a UE remains in the RRC_INACTIVE state by dividing the sum of the durations spent in the RRC_INACTIVE state during the observation period within the RAN-based notification area by the total number of UEs counted during the observation period within the RAN-based notification area. In some embodiments, the node can measure the duration of time spent in the RRC_INACTIVE period based on time T1 (the start time of the observation period) and time T2 (the end time of the observation period). See again Figure 4 The average time can be equal to ((t1'-T1)+(t2'-t2)+(T2-t3)+(t4'-t4)+(t5'-t5)+(T2-T1)) / 6.

[0053] In some examples, the parameters measured by the node may include the duration for which the UE is inactive in each RAN-based notification area. In some embodiments, an inactive UE may reselect from a source cell to another cell (e.g., a target cell). In this case, if the UE remains in the RRC_INACTIVE state, the duration for which the UE remains in the RRC_INACTIVE state continues to be counted. In some examples, the source cell provides the target cell with a time span, i.e., the duration for which the UE is in the RRC_INACTIVE state. If the UE remains in the RRC_INACTIVE state, the target cell may continue counting the duration beyond the received time span. In another example, if the RRC recovery procedure is initiated solely for RAN notification area updates, the duration may be considered to continue. In some examples, the source cell provides the target cell with the cell ID of the cell in which the UE was released from the RRC_CONNECTED state to the RRC_INACTIVE state. In this case, the network node knows the cell ID of the cell in which the inactive UE was released from the RRC_CONNECTED state to the RRC_INACTIVE state.

[0054] In some examples, the node can also determine the number of UEs that remain in the RRC_INACTIVE state for a duration less than or equal to a threshold within each RAN-based notification area during a granularity period. In some examples, the node can also determine the percentage of UEs that remain in the RRC_INACTIVE state for a duration less than or equal to the threshold within each RAN-based notification area during a granularity period. The node can determine the percentage, for example, as the sum of the number of UEs that remain in the RRC_INACTIVE state for a duration less than or equal to the threshold within each granularity period divided by the total number of UEs remaining in the RRC_INACTIVE state within each RAN-based notification area.

[0055] In some embodiments, thresholds and granularity periods can be specified in the network (e.g., NR) specification. In some examples, the thresholds and granularity periods can be configured from the CN to the gNB / eNB. In some examples, the thresholds and granularity periods are provided from the gNB / eNB to the CN (e.g., the thresholds and granularity periods can be determined by the gNB / eNB or a second network node).

[0056] In some embodiments, the node can measure the duration as described above based on each cell of the wireless communication network. The cell to which the UE belongs can be determined by the cell ID associated with the UE. Alternatively, in another alternative, the UE is considered to belong to the cell from which the UE was released from the RRC_CONNECTED state to the RRC_INACTIVE state. Furthermore, a UE in the RRC_INACTIVE state can be considered to belong to the last serving cell. Or, in another example, a UE in the RRC_INACTIVE state is considered to "belong" to the cell storing its AS context. The node can also measure the duration discussed above based on network slices, where a network slice is a logical network serving a specific service or customer need. The node can collect and / or report the number of UEs in the RRC_INACTIVE state for each network slice (e.g., for each network slice, or for one or more specific network slices). The node can also measure the duration discussed above based on PLMNs. For example, the node can collect and / or report the number of UEs in the RRC_INACTIVE state for each PLMN. The node can also measure the duration discussed above based on NPN IDs. For example, a node can collect and / or report the number of UEs in the RRC_INACTIVE state for each non-public network, which can be identified by NPN ID, CAG ID, or any other combination of PLMN ID and NPN ID, PLMN ID and CAG ID, or NPN ID, CAG ID and PLMN ID. The node can perform duration measurements based on various combinations, such as, for example, for each network slice in each PLMN, for each cell in each PLMN, for each network slice in each cell, for each NPN ID in each PLMN, for each cell in each RAN-based notification area, or for each RAN-based notification area in each PLMN. In some embodiments, the UE context may include a timestamp indicating when the UE entered the RRC_INACTIVE state. The node can then use the timestamp to determine the duration the UE remains in the RRC_INACTIVE state.

[0057] A node may report the measurements discussed above to a second network node when one or more conditions are met. For example, a node may report a measurement to a second network node based on determining that the average duration of a UE remaining in the RRC_INACTIVE state is less than or equal to a predefined threshold. In some examples, a node may report a measurement to a second network node based on the following determination: the number of UEs whose duration of remaining in the RRC_INACTIVE state is less than or equal to a threshold time period is less than or equal to a threshold number. In some examples, a node may report a measurement to a second network node based on the following determination: the percentage of UEs whose duration of remaining in the RRC_INACTIVE state is less than or equal to a threshold time period is less than or equal to a threshold percentage value.

[0058] The node can report the duration of the measurement and additional information to the second network node. For example, the report may include the average duration of the UE remaining in the RRC_INACTIVE state, the number of UEs remaining in the RRC_INACTIVE state for a duration less than or equal to a threshold duration value, the percentage of UEs whose duration is less than or equal to the threshold duration value, the time information when the node collects the measurement value, and the corresponding identifier for the measurement granularity (e.g., the physical cell ID used for each cell measurement).

[0059] Thresholds, such as threshold duration values, can be specified in the network specification, or can be configured from the CN to the gNB / eNB, or can be provided from the gNB / eNB to the CN.

[0060] Number of state transitions per granularity period Figure 5 Example state diagram 500 is shown, representing the state machine and state transitions in NR and EUTRA. This node can measure parameters such as UE state transitions and report these transitions to a second network node. Specifically, in one example, the node can measure the total number of transitions from the RRC_INACTIVE / RRC_IDLE state to the RRC_CONNECTED state during each granularity period of each cell. The node can then base its measurement on the data received from each cell during each granularity period. RRCSetupComplete and RRCResumeComplete The total number is determined by the sum of the number of messages. RRCSetupComplete The message indicates that the RRC connection was successfully established, and RRCResumeComplete The message indicates that the RRC connection restoration was successfully completed. The node can also determine the total number based on the difference in the number of UEs in the RRC_CONNECTED state for each cell across two consecutive granularity periods.

[0061] In another example, a node can measure the total number of transitions from the RRC_CONNECTED state to the RRC_INACTIVE state during each granularity period for each cell. In one example, a node can determine the total number for each RAN-based notification area. That is, the node can determine the difference between the number of UEs in the RRC_INACTIVE state in each RAN-based notification area during two consecutive granularity periods. In another example, a node can determine this total for each cell. That is, the node can determine the difference between the number of UEs in the RRC_INACTIVE state in each cell during two consecutive granularity periods.

[0062] In yet another example, the node can measure the total number of transitions from the RRC_INACTIVE state to the RRC_IDLE state. The UE receives this data without any hang-up. RRCRelease Messages or received from the network RRCReject The message transitions from the RRC_INACTIVE state to the RRC_IDLE state. In one example, a node can determine the total number of transitions for each RAN-based notification area. That is, the node can determine the number of pending configuration messages transmitted for each RAN-based notification area during each granularity period. RRCRelease Messages and messages scrambled using Temporary Cell Radio Network Temporary Identifier (TC-RNTI) RRCReject The sum of the number of messages. In another example, a node can determine the total number of transitions for each cell. That is, a node can determine the number of pending configurations transmitted for each cell during each granularity period. RRCRelease And scrambled with TC-RNTI RRCReject The sum of quantities.

[0063] In some embodiments, a node may report the total number of transformations discussed above to a second network node. In some embodiments, a node may report the total number of transformations discussed above to a second network node based on a comparison of the total number with a corresponding threshold. For example, a node may report the total number of transformation values ​​based on a determination that the total number is greater than (or greater than or equal to) or less than (or less than or equal to) a threshold.

[0064] On-demand system information In one embodiment, the node can measure system information and report it to a second network node. System information (SI) is divided into a main information block (MIB) and multiple system information blocks (SIBs). The MIB is always transmitted periodically on the broadcast channel (BCH), containing the information needed to decode SIB1. SIB1 is transmitted periodically on the downlink shared channel (DL-SCH), which carries basic information such as cell (re)selection, access control, and RACH resource configuration. SIBs other than SIB1 are... SystemInformation The SI information is carried in (SI) messages and transmitted over the DL-SCH. Only SIBs with the same periodicity can be mapped to the same SI message. Each SI message is transmitted within a periodically occurring time-domain window (referred to as an SI window of equal length for all SI messages). Each SI message is associated with an SI window, and the SI windows of different SI messages do not overlap. That is, within an SI window, only the corresponding SI message is transmitted. The UE can request system information other than MIBs and SIB1 according to the on-demand SI acquisition procedure, which includes an MSG1-based SI request procedure (if dedicated resources are configured) or an MSG3-based SI request procedure (if no dedicated resources are configured). After receiving a preamble for the SI request, the node or network can broadcast the requested system information. Since the mapping between the preamble and the requested SI message is configured by the network, the node is able to count the SI messages requested during each granularity period.

[0065] In one example, a node can determine the number of SI requests received for each SI message in each cell. In one approach, the node can determine the number of SI request messages received for each SI during each granularity period in each cell (each SI message may include one or more SIBs). In another approach, the node can determine the number of SI requests received for each SIB during each granularity period in each cell. In yet another approach, the node can determine the percentage of transmission time for a SIB, which can be defined as the actual transmission opportunity / potential transmission opportunity during each cell's granularity period.

[0066] In another example, if the SIB is set to region-specific, the node can determine the number of SI requests received for each SI message in each system information region. A system information region is the region to which the region-specific SIB applies. In some implementations, the system information region may consist of one or more cells and be defined by… systemInformationAreaID Mark it. systemInformationAreaIDThis can be unique within a single PLMN. In one approach, a node can determine the number of SI requests received for each SI message during each granularity period of each System Information Area. In another approach, a node can determine the number of SI requests received for each SIB during each granularity period of each cell within each System Information Area. In yet another approach, a node can determine a percentage of transmission time allocated to a SIB, defined as the actual transmission opportunity / potential transmission opportunity during the granularity period.

[0067] Nodes can report measurement information to the management node based on the comparison between the number of SIs or SIBs discussed above and the corresponding thresholds. In one example, if the number of SI-x messages requested during each granularity period is less than, less than or equal to, greater than, or greater than or equal to the corresponding threshold (threshold-x), the node can report the measurement information to the second network node; in this example, x is the index of the SI. In another example, if the number of SIB-x messages requested during each granularity period is less than, less than or equal to, greater than, or greater than or equal to the corresponding threshold, the node can report the measurement information to the second network node; in this example, x is the index of the SIB. In yet another example, if the percentage of transmission time used for a SIB is less than, less than or equal to, greater than, or greater than or equal to the corresponding threshold, the node can report the measurement information to the second network node. Thresholds can be specified in the NR specification, or they can be configured from the core network (CN) to the gNB / eNB, or provided from the gNB / eNB to the CN (e.g., at predetermined intervals determined by the gNB / eNB or the second network node).

[0068] The report provided to the second network node may include the number of SI-x messages requested during each granularity period, the number of SIB-x messages requested during each granularity period, the percentage of transmission time for a SIB message, the time information when the measurement results were collected, and the cell ID or system information area ID in which the measurement results were collected, where x is the index of SI or SIB in this example.

[0069] Dedicated preamble for beam fault recovery (BFR) per beam / per cell The node can also determine the number of dedicated preambles reserved by the BFR received by each beam during each granularity period. Furthermore, the node can count the number of dedicated preambles reserved by the BFR received by each cell or each beam during each granularity period. The node can compare the determined number with a corresponding threshold, and based on the comparison result, can provide the second network node with the value of the number, and / or the beam index, and / or the cell ID and / or the time information when the measurement was performed.

[0070] Number of preambles transmitted by each cell for different RACH types The node can also measure the number of preambles transmitted for various purposes during each granularity period. For example, the node can measure the number of preambles used for two-step RACH per cell during each granularity period. In another example, the node can measure the number of preambles used for four-step RACH per cell during each granularity period. In yet another example, the node can determine the ratio of the number of preambles used for two-step RACH per cell to the number of preambles used for four-step RACH per cell during each granularity period. In yet another approach, the node can determine the percentage of preambles used for two-step RACH relative to the total number of preambles received by each cell during each granularity period. In yet another approach, the node can determine the percentage of preambles used for four-step RACH relative to the total number of preambles received by each cell during each granularity period.

[0071] The node can also measure the number of preambles transmitted on different types of uplink carriers during each granularity period. For example, the node can measure the number of preambles transmitted by each cell on a normal uplink carrier (NUL) during each granularity period. In another example, the node can measure the number of preambles transmitted by each cell on a supplementary uplink carrier (SUL) during each granularity period. In yet another example, the node can determine the ratio of the number of preambles transmitted by each cell on different types of uplink carriers during each granularity period. In yet another approach, the node can determine the percentage of preambles transmitted on SUL relative to the total number of preambles received by each cell during each granularity period. In yet another approach, the node can determine the percentage of preambles transmitted on NUL relative to the total number of preambles received by each cell during each granularity period.

[0072] In another example, the number of preambles used for 2-step RACH and 4-step RACH can be measured in each granularity period of each cell in the Supplementary Uplink Carrier (SUL) and Normal Uplink Carrier (NUL), respectively. For example, a node can measure the number of preambles used for 2-step RACH in the NUL for each cell in each granularity period. In another example, a node can measure the number of preambles used for 2-step RACH in the SUL for each cell in each granularity period. In another example, a node can measure the number of preambles used for 4-step RACH in the NUL for each cell in each granularity period. In yet another example, a node can measure the number of preambles used for 4-step RACH in the SUL for each cell in each granularity period.

[0073] The node can compare the quantity determined above with the corresponding threshold, and based on the comparison result, can provide the second network node with at least one of the following parameters: the value of the quantity, RACH type, uplink carrier type, cell ID, and time information when the measurement is performed.

[0074] II. Measurements performed by the UE The following discussion focuses on measurements that can be performed by the UE and reported to the first network node (e.g., the base station). Figure 6 A schematic diagram illustrating message exchange between UE 600 and gNB 602 is shown to facilitate the transmission of measurement reports from the UE to the gNB. In some embodiments, gNB 602 may be a node such as the second node discussed above. In some embodiments, eNB 602 may be communicatively coupled to the second node and may relay measurement reports provided by UE 600 to the second node. Communication between UE 600 and gNB 602 may include at least three steps. In step 1 (604), UE 600 may transmit a message to gNB 602 indicating the availability of measurement reports. In response, in step 2 (606), gNB 602 may transmit a message to UE 600 requesting measurement reports. In response to receiving a request for measurement reports from gNB 602, in step 3 (608), UE 600 may transmit the measurement reports to gNB 602.

[0075] UE 600 may indicate the availability of one or more measurement reports in step 1 (604). For example, the reports may include RACH success reports, RACH failure reports, RLF reports, etc. Each of these measurement reports is discussed below.

[0076] In some embodiments, the first network node may determine more parameters based on information reported from the UE side. In some embodiments, the first network node may periodically report the measured parameters to the second network node. The reporting period may be specified in the specification, or configured from the second network node (e.g., CN) to the first network node (e.g., gNB / eNB), or configured by the first network node and provided to the second network node from the first network node. In some embodiments, the first network node may report the measured parameters to the second network node if the measured parameters are below, below or equal to, above, or above or equal to a configured threshold. The threshold may be specified in the specification, or configured from the second network node (e.g., CN) to the first network node (e.g., gNB / eNB), or configured by the first network node and provided to the second network node from the first network node.

[0077] RACH Success Report The RACH success report may store measurements related to the successful completion of RACH by the UE 600. In some embodiments, the RACH success report may not include measurements related to the first successful RACH, as these measurements may be included in the RLF report. In some examples, the RACH report may include information about one or more triggering events that triggered the measurements performed by the UE 600. Triggering events may include at least one of the following, for example: initial access initiated in the RRC_IDLE state, an RRC connection re-establishment process, the arrival of DL or UL data during the RRC_CONNECTED state when the UL synchronization state is “asynchronous”, the arrival of UL data during the RRC_CONNECTED state but the SR has no available PUCCH resources, an SR failure, an RRC request for synchronization reconfiguration (e.g., during handover), a transition from the RRC_INACTIVE state, the establishment of time synchronization upon SCell addition, a request for recovery from other SI or beam failures.

[0078] The RACH report may also include a connection failure time indicating the time elapsed from the last handover initialization to the connection failure. The RACH report may also include the time since the failure, indicating the time elapsed since the connection establishment failure. The RACH report may also include a list of beam indices for the beams in which the UE has attempted the RACH procedure. The RACH report may also include the beam type (e.g., SSB or CSI-RS) for each beam in which the UE has attempted the RACH procedure. The RACH report may additionally include the number of preambles transmitted for each beam in which the UE attempted the RACH. If the RACH is triggered by a BFR, the RACH report may also include the index of the beam in which the BFR occurred. If the RACH is triggered by a BFR, the RACH report may also include a BFR timestamp indicating the absolute time of the BFR occurrence. The RACH report may also include parameters. contentionDetected This parameter indicates that at least one transmitted preamble has detected a race condition. The RACH report may also include parameters. maxTxPowerReachedThis parameter determines whether the maximum power level is used for the last transmitted preamble. The RACH report may also include a success timestamp indicating the absolute time of successful RACH completion. The RACH report may also include a RACH type indicator, selectable between two-step and four-step RACH attempts. In some examples, the RACH type may be determined by the RACH type of the first RACH attempt. In another example, the RACH type may be determined by the RACH type of the most recent RACH attempt. The RACH report may also include the number of four-step RACH attempts during the RACH process. The RACH report may also include the number of two-step RACH attempts during the RACH process. The RACH report may also include a backoff indicator, which can be set to true if at least one backoff occurs during the RACH process. The RACH report may also include the number of preambles transmitted via SUL and / or the number of preambles transmitted via NUL. The above list of items in the RACH report is not exhaustive, and the RACH report may include a combination of any of the above items and any additional measurements performed by the UE.

[0079] RACH Fault Report In the event of a RACH failure, the UE can declare a Radio Link Failure (RLF) and select a suitable cell to re-establish the RRC connection by initiating a RACH. RACH-related measurements performed by the UE prior to declaring the RLF can be stored in the RACH failure report. Conversely, RLF-related measurements (including RACH-related measurements during RRC connection re-establishment) can be stored in the RLF report. In some embodiments, the RACH failure report can be included in the RLF report.

[0080] RACH fault reports may include information about one or more triggering events that triggered measurements performed by the UE. For example, triggering events may include initial access initiated in the RRC_IDLE state, an RRC connection re-establishment process, the arrival of DL or UL data during the RRC_CONNECTED state when the UL synchronization state is “asynchronous,” the arrival of UL data during the RRC_CONNECTED state but the SR lacking available PUCCH resources, an SR fault, an RRC request for synchronization reconfiguration (e.g., during handover), a transition from the RRC_INACTIVE state, the establishment of time synchronization upon SCell addition, requests for other SIs, and beam fault recovery events.

[0081] The RACH failure report may also include the connection failure time, indicating the time elapsed from the last handover initialization to the connection failure. The RACH failure report may also include the time since the failure, indicating the time elapsed since the connection (establishment) failure. The RACH failure report may also include a list of beam indices for the beams in which the UE has attempted the RACH procedure. The RACH failure report may also include the beam type (e.g., SSB or CSI-RS) for each beam in which the UE has attempted the RACH procedure. The RACH failure report may also include the number of preambles transmitted for each beam in which the UE attempted the RACH. If the RACH is triggered by a BFR, the RACH failure report may also include the index of the beam in which the BFR occurred. If the RACH is triggered by a BFR, the RACH failure report may also include a BFR timestamp indicating the absolute time of the BFR occurrence. The RACH failure report may also include parameters. contentionDetected This parameter can indicate that at least one transmitted preamble has detected a contention. The RACH fault report may also include BFR location information indicating the location where the BFR occurred. The RACH fault report may also include parameters. maxTxPowerReached This parameter indicates whether the maximum power level was used for the last transmitted preamble. The RACH failure report may also include a RACH type indicator, which can be selected from two-step and four-step RACH attempts. In some examples, the RACH type may be determined by the RACH type of the first RACH attempt. In another example, the RACH type may be determined by the RACH type of the latest RACH attempt. The RACH failure report may also include the number of two-step RACH attempts and / or the number of four-step RACH attempts during the RACH process. The RACH failure report may also include a backoff indication, which can be set to true if at least one backoff occurred during this RACH process. The RACH report may also include the number of preambles transmitted via SUL and / or the number of preambles transmitted via NUL. The above list of items in the RACH report is not exhaustive, and the RACH report may include a combination of any of the above items and any additional measurements performed by the UE.

[0082] RLF Report The RLF report may include measurements related to radio link failures prior to successful RRC connection establishment. The RLF report may include RACH failure reports discussed above. The RLF report may also include BFR indications, for example, when an RLF is triggered by an unsuccessful completion of a BFR. The RLF report may also include a C-RNTI, indicating the C-RNTI used in the PCell when a radio link failure is detected, or the C-RNTI used in the source PCell during a handover failure. The RLF report may also include the connection failure type, indicating whether the connection failure is due to a radio link failure or a handover failure. The RLF report may also include the faulty PCell ID, indicating the PCell where the RLF was detected or the target PCell for the handover failure. The UE can set the E-UTRA Absolute Radio Channel Number (EARFCN) based on the frequency band used for transmission / reception at the time of the failure. The RLF report may also include the faulty cell ID, indicating the cell where the connection establishment failed. The RLF report may also include the previous PCell ID, indicating the source PCell of the last handover (when a signal was received including...). mobilityControlInfo The source PCell when the last RRC connection reconfiguration message is received. The RLF report may also include the rebuild cell ID, which indicates the cell in which a rebuild attempt was made after the connection failure. The RLF report may also include the RLF reason, indicating the cause of the last detected radio link failure. In the case of switching fault information reporting (i.e., connectionFailureType (Set to HOF), the UE can set this field to any value. The RLF report may also include an RLF timestamp, indicating the absolute time the RLF occurred. The RLF report may also include RLF location information, indicating the location where the RLF occurred. The RLF report may also include the time of the connection failure, indicating the time elapsed from the last handover initialization to the connection failure. The RLF report may also include the time since the failure, indicating the time elapsed since the connection (establishment) failure. The RLF report may also include a list of beam indices for the beams in which the UE has attempted RACH procedures. The RLF report may also include the beam type (e.g., SSB or CSI-RS) for each beam in which the UE has attempted RACH procedures. The RLF report may also include the number of preambles sent for each beam in which the UE attempted RACH. The RLF report may also include... contentionDetected It can indicate that at least one transmitted preamble has detected a race condition. The RLF report may also include... maxTxPowerReachedIt can indicate whether the maximum power level was used for the preamble in the last transmission. The RLF report may also include a success timestamp, indicating the absolute time when the RACH was successfully completed. The RLF report may further include information included in the RACH failure report, or include the RACH failure report, wherein the RACH failure report includes information on the latest failed RACH procedure before re-establishing or establishing the RRC connection. The RLF report may further include information included in the RACH success report, or include the RACH success report, wherein the RACH success report includes information on the RACH procedure initiated for successfully re-establishing or establishing the RRC connection after the RLF. The above list of items in the RLF report is not exhaustive, and the RLF report may include a combination of any of the above items and any additional measurements performed by the UE.

[0083] Other RACH-related measurements In addition to measurements performed by the UE, nodes or base stations receiving measurement information from the UE can determine additional measurement parameters based on the received measurement reports. For example, a node can determine the success rate of two-step RACH for each cell during each granularity period. This success rate can be determined based on the ratio of the total number of successfully completed two-step RACH procedures to the total number of two-step RACH procedures initiated by each cell during each granularity period. Regardless of the total number of preambles transmitted, each initiated RACH procedure can only be counted once.

[0084] In some examples, nodes can also determine the success rate of two-step RACH that does not require backoff for each cell during each granularity period. This value can be determined based on the ratio of the total number of two-step RACH processes successfully completed without backoff during the RACH process to the total number of two-step RACH processes initiated by each cell during each granularity period. Regardless of the total number of preambles transmitted, each initiated RACH process can only be counted once.

[0085] In some examples, nodes can further determine the success rate of the four-step RACH process for each cell during each granularity period. This success rate can be determined based on the ratio of the total number of successfully completed four-step RACH processes to the total number of four-step RACH processes initiated by each cell during each granularity period. Regardless of the total number of preambles transmitted, each initiated RACH process can only be counted once.

[0086] In some examples, the node can also determine the number of backoffs per cell during each granularity period. This number can be determined based on the number of two-step RACH procedures initiated by each cell when a backoff occurs during each granularity period. In another example, the node can also determine the probability of a backoff occurring per cell during each granularity period. This value can be determined based on the ratio of the total number of two-step RACH procedures initiated when a backoff occurs during a RACH procedure to the total number of two-step RACH procedures initiated by each cell during each granularity period. Regardless of the total number of preambles transmitted, each initiated RACH procedure can only be counted once.

[0087] For the above measurements, a threshold can be configured for comparison. If the measured value is higher than, higher than or equal to, lower than, or lower than or equal to the threshold, the node will be triggered to report the result to the second node or the CN. The threshold can be specified in the NR specification, or it can be configured from the core network (CN) to the gNB / eNB, or it can be provided from the gNB / eNB to the CN (e.g., at predetermined intervals determined by the gNB / eNB or the second node).

[0088] The node can perform the above-mentioned additional RACH-based calculations based on information provided by the UE (e.g., RACH reports, RLF reports, etc.).

[0089] Beam correlation measurement In some examples, a node can determine the value of one or more parameters based on information and reports received from the UE. In some examples, a node can determine the number of BFRs for each beam during each granularity period. In one approach, the number of BFRs can be obtained as the sum of the total number of RACH failures (triggered by a "BFR") for each beam during each granularity period, calculated based on reports collected from the UE. In another approach, whenever a BFR occurs, the UE can indicate the occurrence of the BFR and the beam index to the node by transmitting a coded signal via PUCCH. The node can then calculate the total number of BFRs occurring for each beam during each granularity period based on the received information.

[0090] In another example, the node can determine the average number of attempts required to successfully complete the BFR for each beam. This average number is obtained by dividing the sum of the number of preambles transmitted for each beam in which the UE has attempted to perform the RACH procedure (where the trigger event is "BFR") in the RACH success reports collected in each granular period by the number of RACH success reports collected in each granular period (where the trigger event is "BFR").

[0091] In yet another example, a node can determine the average number of attempts required to successfully restore the connection after triggering the BFR for each beam. This number can be obtained by dividing the sum of the number of preambles transmitted for each beam in RACH success reports and RACH failure reports (triggered by the BFR event) and in RLF reports (where RACH failure reports are included and collected in each granularity period), by the sum of the number of RACH success reports, RACH failure reports, and RLF reports (where RACH failure reports are included and collected in each granularity period).

[0092] In another example, a node can determine the average time required for each cell to successfully complete a BFR during each granularity period. The average time can be obtained as: the sum of the durations of successful RACH completion in each RACH success report (where the triggering event is "BFR") collected by each cell in each granularity period, divided by the number of RACH success reports collected by each cell in each granularity period, where the duration of successful RACH completion in each RACH success report can be obtained as: the time difference between the success timestamp and the BFR timestamp in the RACH success report.

[0093] In another approach, the node can determine the average time required to successfully restore the RRC connection after triggering a BFR in each cell. The average time can be obtained as: the sum of the durations of successful RRC connection restoration per granularity period for each cell, divided by the number of RACH success reports and RLF reports collected per granularity period for each cell. The duration of successful RRC connection restoration includes the duration of successful RACH completion in the RACH success report triggered by a BFR, and the duration of successful RRC restoration in the RLF report containing a BFR indication. The duration of successful RRC restoration can be obtained as the time difference between the success timestamp in the RACH failure report and the BFR timestamp.

[0094] How does the UE decide whether to perform a measurement? As mentioned above Figure 6 As discussed, in step 1, the UE indicates the availability of a report to the gNB. However, the UE's execution of the procedure for including measurements in the report can be based on certain conditions. In the first aspect, a UE capable of performing measurements can always perform supported measurements in response to a set of triggering events. For example, for RLF-related measurements, the UE can always measure the relevant measurement when an RLF is detected and store the relevant measurement in memory to report to the gNB.

[0095] In the second aspect, the UE can perform measurements based on the measurement configuration received from the network.

[0096] In the third aspect, the UE can perform measurements when triggered by an event, where the triggering event can be at least one of the following: initiation of a random access procedure, an RLF, and events A1 to A6 and events B1 to B2 as defined in the protocol. These events are also described in Section 5.5.4 of TS38331, and can point to event A1: serving cell quality is better than a threshold, event A2: serving cell quality is worse than a threshold, event A3: neighboring cell quality is better than a certain threshold of SpCell, event A4: neighboring cell becomes better than a threshold, event A5: SpCell becomes worse than threshold 1 and neighboring cell becomes better than threshold 2, event A6: neighboring cell service quality is better than a certain threshold of SCell, event B1: cross-RAT neighboring cell becomes better than a threshold, and event B2: PCell becomes worse than threshold 1 and cross-RAT neighboring cell becomes better than threshold 2.

[0097] In the fourth aspect, the UE can perform measurements under the control of the network. In one example, the measurement list can be predefined or configured by the network. The configuration may include, for example, " L2MeasRequest_i ", 1 <= i <= 2 Num_of_MeasType -1, where Num_of_MeasType This equals the total number of defined measurement types. Each measurement list (including lists of different measurement types) can be used to enable one or more executable measurement types. Each type of measurement can include a series of measurements. For example, if there are RLF-related measurements, RACH-related measurements, and mobility-related measurements, the requested measurement list can be considered as: L2MeasRequest_1: RLF-related measurements; L2MeasRequest_2: RACH-related measurements; L2MeasRequest_3: Mobility-related measurements; L2MeasRequest_4 : RLF-related measurements, RACH-related measurements; L2MeasRequest_5 : RLF-related measurements, mobility-related measurements; L2MeasRequest_6 Mobility-related measurements, RACH-related measurements; L2MeasRequest_7 : RLF-related measurements, RACH-related measurements, mobility-related measurements.

[0098] Nodes or networks can broadcast a list of requested measurements to be performed by the UE, or this list can be transmitted in system information or via RRC signaling. For example, if the UE receives a list including... L2MeasRequest_1 If a reconfiguration message is received, and an RLF occurs and the procedure is followed as shown in the General Procedure section, the UE can perform RLF-related measurements.

[0099] In another example, a bitmap can be used to map each bit to a measurement type. A "0" indicates that the corresponding measurement does not need to be performed, while a "1" indicates that the corresponding measurement needs to be performed upon triggering. The mapping of measurement types to each bit can be predefined in the protocol or configured by the network. The mapping and the bitmap used to enable a specific type of measurement can be delivered to the UE via broadcast information, system information, or RRC signaling. For example, if there are three types of measurements, a 3-bit bitmap can be used to enable each type of measurement; for instance, a bitmap equal to "101" means enabling the first and second types of measurements.

[0100] Any combination of the above aspects can also be used. For example, the fourth aspect discussed above can be combined with the second or third aspect. The fourth aspect discussed above can be used to indicate whether a certain type of measurement is allowed to be performed by the UE, and the actual time for performing the measurement is based on the measurement configuration or the time when the triggering event occurs.

[0101] How does the UE indicate the availability of the measurement to be acquired? refer to Figure 6 Step 1, as shown below, discusses the conditions under which the UE can indicate the availability of one or more reports to the gNB. In NR, RACH resources (e.g., RACH timing and preamble) are closely related to the beam, and some measurements are also performed at the beam level. Introducing beam-level measurements helps to better manage beams and configure resources. Due to changes in the network environment, user mobility, interference from other users, etc., beam quality and correspondences are constantly changing. Therefore, it is helpful to find an effective way to report beam-related measurement results to ensure the validity of the measurements, or in other words, to keep the measurement results up-to-date. When a beam failure is detected, the UE can trigger a BFR procedure by initiating a RACH procedure to attempt to find a suitable beam to perform the BFR.

[0102] The availability of a report can be indicated to a node in several ways. In one approach, the indication or a list of indications can be sent via an RRC message (e.g., RRCSetupCompleteThe message is sent. In some examples, each indication is used to indicate the availability of a specific type of measurement report; for example, carrying an indication means that a corresponding report is available, while not carrying an indication means that no corresponding measurement report is available. Or in another example, setting an indication to "1" means that a corresponding report is available, while setting an indication to "0" means that no corresponding measurement report is available. In the second method, the indication or list of indications can be sent via signals transmitted in the PUCCH. In the third method, the indication can be sent using a MAC control element (MAC-CE). For example, the message may include "UE InfoAvailable MAC CE", identified by a MAC sub-header, where the LCID is equal to one of the reserved values ​​specified in the protocol. The MAC-CE can be zero bits long, indicating that the UE information report is available upon receipt of a UE Info Available MAC CE. Or in another example, the MAC-CE can be N octets long, containing a bitmap where each bit maps to a type of measurement report. "0" indicates that the corresponding measurement report is unavailable, while "1" indicates that the corresponding measurement is available. The mapping from measurement report types to each bit can be predefined in the protocol or configured by the network. If the total number of measurement report types is less than 8*N, the remaining bits of this MAC CE can be reserved. Reserved bits can always be set to "0". Any combination of the four methods described above can also be used.

[0103] In some embodiments, after successful RACH completion, the relevant measurement results can be stored in the RACH success report. If the payload portion of Msg3 in a four-step RACH or Msg1 in a two-step RACH contains an RRC message, subsequent RRC messages (e.g., RRCResumeComplete, RRCSetupComplete , RRCReestablishmentComplete ,or RRCReconfigurationComplete ) can contain information elements (IE) (e.g., " RACHSuccess- InfoAvailability This indicates the availability of a successful RACH report. For example, after completing RRC connection setup, the UE can indicate this by... RRCSetupComplete Lieutenant General RACHSuccess-InfoAvailability "Set to true" indicates that a RACH success report is available. In another example, the UE may indicate the availability of a RACH success report as soon as possible after a successful RACH completion by using a signal similar to a scheduling request (SR) transmitted in a PUCCH, or by transmitting a MAC CE (e.g., "RACH Success InfoAvailable MAC CE") to the base station.

[0104] In instances where a RACH failure occurs, the UE can claim a Radio Link Failure (RFL) and attempt to select a suitable cell to re-establish the RRC connection by initiating a RACH. RACH-related measurements can be stored in the RACH failure report, and other RLF-related measurements can also be stored in the RLF report. Furthermore, the RACH failure report can be included in the RLF report. The UE can indicate the availability of the RLF report at each subsequent LTE RRC connection (re)establishment, RRC connection recovery, or handover, which can be done by including an IE in the RRC message, for example, in RRCResumeComplete , RRCSetupComplete , RRCReestablishmentComplete or RRCReconfigurationComplete "in rlf- InfoAvailable In addition, it is possible to RRCResumeComplete , RRCSetupComplete , RRCReestablishmentComplete or RRCReconfigurationComplete It includes IE, for example, " RACHFailure-InfoAvailability "" indicates the availability of RACH fault reports.

[0105] When to clear stored measurement results Related to step 3 discussed above (see reference) Figure 6 Regarding the measurement report, the UE can clear it from memory under certain conditions. For example, in the first method, the UE can clear the measurement result immediately after reporting it to the node. In the second method, the UE can clear the measurement result from memory after receiving a positive confirmation from the node that the measurement report has been successfully received. In the third method, the UE can continue to store the measurement report until the next measurement is triggered. In the fourth method, different validity periods can be configured for different measurement quantities. If the measurement result has not yet been acquired and the validity period has expired, the measurement result will be cleared. The validity period can be configured by the network, by the CN, by a second network node, or predefined in the protocol. Furthermore, any combination of the above four methods can be used to determine when to clear the measurement report at the UE.

[0106] While various embodiments of the solution have been described above, it should be understood that they are presented by way of example only and not by way of limitation. Similarly, various figures may depict example architectures or configurations, provided to enable those skilled in the art to understand example features and functionality of the solution. However, those skilled in the art will understand that the solution is not limited to the example architectures or configurations shown, but can be implemented using various alternative architectures and configurations. Furthermore, as those skilled in the art will understand, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of this disclosure should not be limited by any of the illustrative embodiments described above.

[0107] It should also be understood that any references to elements in this document using names such as "first," "second," etc., generally do not restrict the number or order of those elements. Rather, these names may be used herein as a convenient means of distinguishing between two or more elements or examples of elements. Therefore, references to first and second elements do not imply that only two elements can be used, or that the first element must somehow precede the second element.

[0108] Furthermore, those skilled in the art will understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols, as referenced in the above description, can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0109] Those skilled in the art will further understand that any of the various illustrative logic blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, various forms of design code or programs containing instructions (which may be referred to herein as "software" or "software module" for convenience), or any combination of these technologies. To clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been described above in general according to their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functionality in various ways for each specific application, but such implementation decisions will not depart from the scope of this disclosure.

[0110] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein can be implemented within or executed by integrated circuits (ICs), which can include: general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, or any combination thereof. Logic blocks, modules, and circuits may further include antennas and / or transceivers for communication with various components within a network or device. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other suitable configuration to perform the functions described herein.

[0111] If a function is implemented in software, that function can be stored as one or more instructions or code on a computer-readable medium. Therefore, the steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, with communication media including any medium capable of transferring a computer program or code from one place to another. A storage medium can be any available medium accessible to a computer. By way of example and without limitation, such a computer-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0112] In this document, the term "module" as used herein refers to software, firmware, hardware, and any combination of these elements used to perform the associated functions described herein. Furthermore, for the purposes of discussion, various modules are described as discrete modules; however, it will be apparent to those skilled in the art that two or more modules can be combined to form a single module that performs the associated functions according to embodiments of the present solution.

[0113] Additionally, in embodiments of this solution, memory or other storage devices and communication components may be employed. It should be understood that, for clarity, the above description has referenced various functional units and processors in describing embodiments of this solution. However, it will be apparent that any suitable functional distribution among different functional units, processing logic elements, or domains can be used without departing from this solution. For example, a function illustrated as being performed by a separate processing logic element or controller may be performed by the same processing logic element or controller. Therefore, references to specific functional units are merely references to appropriate means for providing the described functionality and do not indicate a strict logical or physical structure or organization.

[0114] Various modifications to the embodiments described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but is to be endowed with the widest scope consistent with the novel features and principles disclosed herein, as set forth in the following claims.

Claims

1. A wireless communication method, the method being performed by a user equipment, comprising: Send a message to the wireless communication node indicating the availability of at least one measurement report; Receive a message from the wireless communication node requesting the at least one measurement report; Send the at least one measurement report to the wireless communication node. The at least one measurement report includes at least one of the following: Information indicating whether the random access channel RACH type is two-step random access or four-step random access; The number of preambles transmitted during the RACH process; A list of beam indices that were attempted during the RACH process; The beam type of each beam attempted during the RACH process; A rollback instruction indicating whether a rollback has occurred.

2. The method according to claim 1, wherein, The at least one measurement report also includes at least one of the following: The number of preambles transmitted on different uplink carrier types, wherein the different uplink carrier types are normal uplink carrier NUL or supplementary uplink carrier SUL; A success timestamp indicating the absolute time when RACH was successfully completed.

3. The method according to claim 1 or 2, wherein, The at least one measurement report includes a RACH success report and / or a RACH failure report.

4. The method according to claim 1, wherein, Sending a message to the wireless communication node indicating the availability of at least one measurement report, including: The indication is transmitted via at least one of Radio Resource Control (RRC), Physical Uplink Control Channel (PUCCH), and Media Access Control (MAC) Control Element (MAC-CE).

5. The method according to claim 1, characterized in that, Also includes: After sending the at least one measurement report to the wireless communication node, the stored sent measurement report is cleared.

6. A wireless communication method, the method being executed by a first wireless communication node, comprising: Measure at least one parameter associated with a wireless communication network, the at least one parameter including the number of preambles for a two-step random access channel RACH and / or the number of preambles for a four-step RACH; The at least one parameter is reported to the second wireless communication node.

7. The method according to claim 6, characterized in that, The at least one parameter also includes at least one of the following: The number of preambles transmitted on a normal uplink carrier NUL; The number of preambles transmitted on the supplementary uplink carrier SUL; The number of preambles used for two-step RACH transmitted on the normal uplink carrier NUL; The number of preambles used for four-step RACH transmitted on the normal uplink carrier NUL; The number of preambles used for two-step RACH transmitted on the supplementary uplink carrier SUL; The number of preambles used for the four-step RACH transmitted on the supplementary uplink carrier SUL; The ratio of the number of preambles used for two-step RACH to the number of preambles used for four-step RACH; The percentage of preambles used for two-step or four-step RACH compared to the total number of preambles transmitted in the cell during the measurement period; The ratio of the number of preambles transmitted on NUL to the number of preambles transmitted on SUL; The percentage of the number of preambles transmitted on NUL or SUL relative to the total number of preambles transmitted in the cell during the measurement period.

8. The method according to claim 6 or 7, wherein, The measurements are performed for each cell within the measurement period.

9. The method according to claim 6, wherein, Reporting the at least one parameter to the second wireless communication node includes: Compare the measured number of preambles for two-step RACH and / or the number of preambles for four-step RACH with the corresponding thresholds; A report is triggered to the second wireless communication node based on the comparison result.

10. A wireless communication device, characterized in that, Includes a processor and memory, the memory storing instructions that, when executed by the processor, configure the processor to perform the following operations: Send a message to the wireless communication node indicating the availability of at least one measurement report; Receive a message from the wireless communication node requesting the at least one measurement report; Send the at least one measurement report to the wireless communication node. The at least one measurement report includes at least one of the following: Information indicating whether the random access channel RACH type is two-step random access or four-step random access; The number of preambles transmitted during the RACH process; A list of beam indices that were attempted during the RACH process; The beam type of each beam attempted during the RACH process; A rollback instruction indicating whether a rollback has occurred.

11. The device according to claim 10, wherein, The at least one measurement report also includes at least one of the following: The number of preambles transmitted on different uplink carrier types, wherein the different uplink carrier types are normal uplink carrier NUL or supplementary uplink carrier SUL; A success timestamp indicating the absolute time when RACH was successfully completed.

12. The device according to claim 10 or 11, wherein, The at least one measurement report includes a RACH success report and / or a RACH failure report.

13. The device according to claim 10, wherein, Sending a message to the wireless communication node indicating the availability of at least one measurement report, including: The indication is transmitted via at least one of Radio Resource Control (RRC), Physical Uplink Control Channel (PUCCH), and Media Access Control (MAC) Control Element (MAC-CE).

14. The device according to claim 10, characterized in that, The processor is also configured to: After sending the at least one measurement report to the wireless communication node, the stored sent measurement report is cleared.

15. A wireless communication device, characterized in that, Includes a processor and memory, the memory storing instructions that, when executed by the processor, configure the processor to perform the following operations: Measure at least one parameter associated with a wireless communication network, the at least one parameter including the number of preambles for a two-step random access channel RACH and / or the number of preambles for a four-step RACH; The at least one parameter is reported to the second wireless communication node.

16. The device according to claim 15, characterized in that, The at least one parameter also includes at least one of the following: The number of preambles transmitted on a normal uplink carrier NUL; The number of preambles transmitted on the supplementary uplink carrier SUL; The number of preambles used for two-step RACH transmitted on the normal uplink carrier NUL; The number of preambles used for four-step RACH transmitted on the normal uplink carrier NUL; The number of preambles used for two-step RACH transmitted on the supplementary uplink carrier SUL; The number of preambles used for the four-step RACH transmitted on the supplementary uplink carrier SUL; The ratio of the number of preambles used for two-step RACH to the number of preambles used for four-step RACH; The percentage of preambles used for two-step or four-step RACH compared to the total number of preambles transmitted in the cell during the measurement period; The ratio of the number of preambles transmitted on NUL to the number of preambles transmitted on SUL; The percentage of the number of preambles transmitted on NUL or SUL relative to the total number of preambles transmitted in the cell during the measurement period.

17. The device according to claim 15 or 16, wherein, The measurements are performed for each cell within the measurement period.

18. The device according to claim 15, wherein, Reporting the at least one parameter to the second wireless communication node includes: Compare the measured number of preambles for two-step RACH and / or the number of preambles for four-step RACH with the corresponding thresholds; A report is triggered to the second wireless communication node based on the comparison result.

19. A computer-readable storage medium storing instructions, wherein, When executed by a processor, the instructions cause the processor to implement the method as described in any one of claims 1-9.

Images