System and method for performing and reporting measurements in a wireless communication network

Abstract

Disclosed herein is a system and method for measuring network parameters of a wireless communication network and reporting the measured network parameters to a network node. In one embodiment, the system and method are configured to determine, by a wireless communication node, at least one parameter related to a wireless communication device in a wireless communication network; compare, by the wireless communication node, the at least one parameter to at least one threshold; and report, by the wireless communication node, the at least one parameter to a second network node associated with the wireless communication network in accordance with a result of the comparison.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communications, and more specifically, to systems and methods for configuring ad hoc networks. BACKGROUND

[0002] Ad hoc network technology requires automatic configuration of network elements when deployed into a network environment. Network elements such as user equipment and nodes can be configured in real-time based on current network conditions. SUMMARY

[0003] The example 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 to those of ordinary skill in the art upon reading the following detailed description in conjunction with the accompanying drawings. In accordance with various embodiments, example systems, methods, devices, and computer program products are disclosed herein. It should be understood, however, that these embodiments are set forth by way of example and not by way of limitation, and that modifications to the disclosed embodiments can occur to those skilled in the art upon reading the present disclosure, which are intended to be within the scope of the present disclosure.

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

[0005] In another embodiment, a method performed by a wireless communication device includes transmitting, to a wireless communication node, a message indicating availability of at least one measurement report. The method further includes receiving, from the wireless communication node, a message requesting the at least one measurement report. The method further includes measuring at least one parameter based on the at least one measurement report. The method further 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.

[0006] The above and other aspects and embodiments thereof will be more apparent from the following drawings, description, and claims. BRIEF DESCRIPTION OF DRAWINGS

[0007] Various example embodiments of the present solution are described in detail below with reference to the following drawings or figures. The drawings are provided for purposes of illustration only and merely depict example embodiments of the present solution to facilitate the reader's understanding of the present solution. Accordingly, the drawings should not be considered limiting the breadth, scope, or applicability of the present solution. It should be noted that for clarity and ease of illustration, these drawings are not necessarily made to scale.

[0008] Figure 1 An example cellular communication network in which the techniques and other aspects disclosed herein can be implemented is shown in accordance with embodiments of the present disclosure.

[0009] Figure 2 Block diagrams of example base stations and user devices in accordance with some embodiments of the present disclosure are shown.

[0010] Figure 3 A schematic diagram of downlink packet transmission from a node to a user device in accordance with some embodiments of the present disclosure is shown.

[0011] Figure 4 An example timing diagram depicting durations in which various user devices remain in an inactive state in accordance with some embodiments of the present disclosure is shown.

[0012] Figure 5 An example state diagram representing state transitions and state machines for user devices in a wireless communication network in accordance with some embodiments of the present disclosure is shown.

[0013] Figure 6 A schematic diagram depicting message exchange between a user device and a node to facilitate transmission of measurement reports in accordance with some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0014] Various example embodiments of the present solution are described below with reference to the accompanying drawings or figures to enable a person of ordinary skill in the art to make and use the present solution. As will be apparent to those of ordinary skill in the art upon reading this disclosure, various changes or modifications can be made to the examples described herein without departing from the scope of the present solution. Thus, the present solution is not limited to the example embodiments and applications described and illustrated herein. Additionally, the particular order or hierarchy of steps in the methods disclosed herein are merely example methods. Based upon design preferences, the particular order or hierarchy of steps of the disclosed methods or processes can be re-arranged, while remaining within the scope of the present solution disclosure. As such, those of ordinary skill in the art will appreciate that the methods and techniques disclosed herein present various steps or acts in a sample order, and the present solution is not limited to the specific order or hierarchy presented unless explicitly stated otherwise.

[0015] Figure 1An example wireless communication network and / or system 100 in accordance with embodiments of the present disclosure is shown in which the technology disclosed herein can be implemented. In the following discussion, the 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 the “network 100.” Such an example network 100 includes base stations 102 (hereinafter “BS 102”) and user equipment 104 (hereinafter “UE 104”) that can communicate with each other via communication links 110 (e.g., wireless communication channels), and includes cell clusters 126, 130, 132, 134, 136, 138, and 140 that cover geographic areas 101. In Figure 1 The BS 102 and the UE 104 are contained within respective geographic boundaries of the cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 can include at least one base station operating over its allocated bandwidth to provide sufficient wireless coverage to its intended users.

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

[0017] 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) in accordance with some embodiments of the present solution is shown. The system 200 can include components and elements configured to support known or conventional operational features that need not be described in detail herein. In one illustrative embodiment, the system 200 can be used to communicate (e.g., transmit and receive) data symbols in a wireless communication environment, such as the wireless communication environment 100 described above. Figure 1

[0018] ​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.

[0019] 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.

[0020] 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 time-coordinated 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.

[0021] UE transceiver 230 and base station transceiver 210 are configured to communicate via wireless data communication link 250, in cooperation with appropriately configured RF antenna arrangements 212 / 232, which can support particular wireless communication protocols and modulation schemes. In some illustrative embodiments, UE transceiver 210 and base station transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be appreciated that the present disclosure is not necessarily limited in application to particular standards and related protocols. Rather, UE transceiver 230 and base station transceiver 210 can be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0022] According to various embodiments, BS 202 can be an evolved Node B (eNB), a serving eNB, a target eNB, a femto station, or a pico station. In some embodiments, UE 204 can be embodied in various types of user equipment such as a mobile phone, a smart phone, a personal digital assistant (PDA), a tablet computer, a notebook computer, a wearable computing device, etc. Processor modules 214 and 236 can be implemented or realized with a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this manner, the processor can be implemented as a microprocessor, a controller, a microcontroller, a state machine, etc. The processor can also be implemented as a combination of a

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

[0024] Network communication module 218 generally represents the hardware, software, firmware, processing logic and / or other components of base station 202 that enable two-way 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 can be configured to support Internet or WiMAX traffic. In a typical deployment, network communication module 218 provides an 802.3 Ethernet interface, without limitation, such that base station transceiver 210 can communicate with a conventional Ethernet-based computer network. In this manner, network communication module 218 can include a physical interface for connecting to a computer network (e.g., a mobile switching center (MSC)). The terms "configured to," "adapted to," and "arranged to," and their conjugations, as used herein in reference to a specified operation or function, refer to an apparatus, component, circuit, structure, machine, signal, etc., that is physically constructed, programmed, formatted, and / or arranged to perform the specified operation or function.

[0025] Having discussed various aspects of the network environment and the apparatus that can be used to implement the systems, methods and apparatus described herein, additional details will be followed.

[0026] Self-organizing networks (SON) can be divided into three categories: self-configuration, self-optimization, and self-healing. The functions of SON can include load balancing, coverage and capacity optimization, energy saving, random access channel (RACH) optimization, etc. These functions can be based on a large number of collected measurements, e.g., information reports from the UE side and performance related measurements collected and derived from the network side. In some cases, SON has been applied in LTE type networks. However, some measurement quantities in LTE type networks can have to be modified so that SON can be adapted for implementation in New Radio (NR) or 5G type networks. The adaptability can also include performing new measurements that can help the operation, administration, and maintenance (OAM) to optimize network configuration and perform efficient mobility management. These measurements can be collected by the UE or by the network.

[0027] I. Measurements by the network

[0028] This section of the discussion focuses on measurements performed by the network, independent of whether any measurements performed at the UE are reported by the UE. As one example, a node, such as, for example, a base station, can measure one or more parameters related to the wireless communication network. The node can compare the value of the one or more measured parameters to a threshold value. Depending on the result of the comparison, the node can report the measured parameter value to a second network node, e.g., a core network (CN), a trace collection entity (TEC), etc. The measured parameters can include, but are not limited to: a radio access network (RAN) part of the downlink delay, a number of UEs in RRC connected state, a number of UEs in RRC inactive state, an average duration of UEs staying in inactive state, a number of UEs staying in RRC INACTIVE state for a duration lower than or equal to certain thresholds (which can be configured by the base station, core network or pre-defined in the protocol), a number of state transitions during each granularity period, a number of on-demand system information requests by UEs, a dedicated preamble for beam failure recovery, and a number of preambles transmitted per cell. The node can compare one or more values of the measured parameters and send the value to a second network node of the wireless communication network. In some embodiments, the node can determine (e.g., select, calculate, identify, etc.) the parameter value during each RAN granularity period based on a notification area. In some embodiments, the node can determine the parameter value during each cell granularity period of the wireless communication network. The granularity period can refer to a time period during which the measurement of one or more parameters is performed. The granularity period can be pre-defined in the specification, or configured by the BS or OAM and provided to the UE, or configured by the core network (CN) and notified to the BS. In some examples, the granularity period can be configured by the BS or OAM and provided to the CN.

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

[0030] In some embodiments, the node can periodically report the measured parameter to the second network node. In some embodiments, the reporting period can be specified in a specification. In some examples, the reporting period can be configured from the second network node (e.g., CN) to the first network node (e.g., 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] Radio access network (RAN) part of downlink delay

[0032] Figure 3 A schematic diagram of downlink data packet transmission from a node to a user equipment is shown. In particular, Figure 3 A schematic diagram of a data packet 300 transmitted during downlink (DL) from a node 302 to a user equipment 304 is shown. The data packet 300 transmission is described with reference to a RAN protocol architecture, including service data application protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), and physical layer (PHY). The total data packet delay during DL within a wireless communication network can consist of a delay in the RAN and a delay in the core network (CN). The delay in the RAN is described in Figure 3 as delay ti, which is equal to the difference between time T2 and T1. This difference can include an average delay during DL air interference + RLC delay, an average delay of DL in CU-UP (user plane of central unit) (this latency is optional in case of CU-DU split), and an average delay on F1 user plane interface (F1-U) (this latency is optional in case of CU-DU split). The 5G radio access network architecture is supported to be split into a central unit (CU) and a distributed unit (DU) to support more flexible transport networks and provide enhanced user experience.

[0033] In one example, the reference point at which the data packet arrives at the UE can be a PDCP upper layer service access point (SAP), while the reference point at which the data packet is successfully received at the UE can be a MAC lower layer SAP. However, in some other examples, since the RAN part of the uplink (UL) delay is calculated as the difference between T2’ and T1, the DL delay measurement can also include the PDCP reordering part at the UE side. That is, the DL delay measurement can also include the time period t2. Thus, the RAN part of the delay can be equal to T2’ - T1. In some embodiments, this difference can be determined (e.g., selected, calculated, identified, etc.) based on the time of receiving the last part of the RLC service data unit (SDU) packet and the sum of the times of all previous RLC SDU packets having been successfully received according to a status report, minus the time of over-the-air transmission of the last part of the same packet divided by the total number of RLC SDUs arriving at the MAC lower layer SAP. In case of RLC SDUs that are to be retransmitted (e.g., for acknowledged mode), the delay will still include only 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 part of the DL delay for each data radio bearer (DRB). In some embodiments, the PDCP reordering delay at the UE side can be reported from the UE to the base station or node.

[0034] Number of UEs in RRC CONNECTED state

[0035] In some examples, the node can measure the number of UEs in 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 traffic 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 needed for communication between the device and the RAN are known to both the device and the node. The node can measure the number of UEs in RRC CONNECTED state during a granularity period. In some examples, the node can determine (e.g., select, calculate, identify, etc.) the maximum number of UEs in RRC CONNECTED state. In some examples, the node can determine the average number of UEs in RRC CONNECTED state during the granularity period. The node can compare the maximum or average number of UEs in RRC CONNECTED state to a threshold value.

[0036] In some examples, the node can report information to the second network node when it is determined that the maximum number of UEs in RRC CONNECTED state is greater than or greater than or equal to a threshold. In some examples, the node can report information to the second network node when it is determined that the maximum number of UEs in RRC CONNECTED state is less than or less than or equal to a threshold. In some examples, the node can report information to the second network node when it is determined that the average number of UEs in RRC CONNECTED state is greater than or greater than or equal to a threshold. In some examples, the node can report information to the second network node when it is determined that the average number of UEs in RRC CONNECTED state is less than or less than or equal to a threshold.

[0037] In some examples, the threshold compared to the maximum number of UEs in RRC CONNECTED state or the threshold compared to the average number of UEs in RRC CONNECTED state can be determined in several ways. For example, the threshold can be specified in a specification, e.g. NR, the threshold can be configured to the first network node, e.g. gNB / eNB, from the second network node, e.g. CN, 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.

[0038] Based on the comparison of the measured values and the corresponding thresholds, the node can report information to the second network node. The information can comprise the maximum and / or average number of UEs in RRC CONNECTED state, time information associated with when the measurements were collected, and corresponding identifiers for the measurement granularity, e.g. physical cell ID for each cell measurement.

[0039] In some examples, the node can determine the average number of UEs in RRC CONNECTED state per granularity period per cell of the wireless communication network. The node can sample the state of the UEs during a predefined interval and determine the number of UEs in RRC CONNECTED state per cell and subsequently determine the arithmetic average of the numbers across all cells. In a similar manner, the node can determine the maximum number of UEs in RRC CONNECTED state by determining the maximum number across all cells. In some examples, the predefined interval can refer to a sampling period within the granularity period. For example, the sampling interval can refer to a time period after which the value of a measurement parameter is measured. The sampling can be repeated several times at intervals in time of the sampling period. The sampling period can be less than the granularity period.

[0040] In some examples, the node can determine (e.g., select, calculate, identify, etc.) maximum values and average values in a context other than each cell measurement discussed above. For example, the node can determine average values and maximum values based on network slices, which are logical networks that serve particular traffic or customer needs. In some such examples, the node can determine maximum values and average values based on values determined across multiple network slices. In some other examples, the node can determine maximum values and average values across multiple public land mobile networks (PLMNs). In some other examples, the node can measure maximum values and average values based on non-public network (NPN) IDs. For example, the node can determine the number of UEs in an RRC CONNECTED state per NPN, which can be identified by one or more of an NPN ID, a CAG ID (where CAG indicates a closed access group), or a PLMN ID. In some embodiments, the node can determine average values and maximum values over various combinations of contexts. For example, the node can determine average values and maximum values based on values determined in each slice per PLMN, or in each cell per PLMN, or for each slice in each cell, or for each NPN ID in each PLMN.

[0041] In some embodiments, the predefined interval (after which the node samples the state of the UE) and the granularity period can be specified in a specification. In some examples, the predefined interval and granularity period can be configured to the gNB / eNB from the CN. 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).

[0042] Number of UEs in RRC INACTIVE state

[0043] In this example, the node can measure an average number and a maximum number of UEs in an RRC INACTIVE state. In a communication network, when an RRC connection is suspended (e.g., by receiving an RRC release message with a suspend indication from the network), the UE can store a UE inactive access stratum (AS) context and any configuration information received from the network, and can transition to an RRC INACTIVE state. In the RRC INACTIVE state, the RAN can configure a RAN-based notification area to the UE, and the UE can perform a RAN-based notification area update periodically and when moving outside the configured RAN-based notification area. In some examples, the last serving eNB can maintain the UE context as well as the UE-associated NG connections with a serving access and mobility management function (AMF) and user plane function (UPF). In some examples, the UE context can be reallocated or released.

[0044] The node can measure the number of UEs in RRC INACTIVE state during each granularity period. Similar to the discussion above regarding determining the number of UEs in RRC CONNECTED state, the node can determine a value of the maximum number or average number of UEs in RRC INACTIVE state. In some examples, the node can report information to the second network node when the determined maximum number of UEs in RRC INACTIVE state is greater than or greater than or equal to a threshold. In some examples, the node can report information to the second network node when the determined maximum number of UEs in RRC INACTIVE state is less than or less than or equal to a threshold. In some examples, the node can report information to the second network node when the determined average number of UEs in RRC INACTIVE state is greater than or greater than or equal to a threshold. In some examples, the node can report information to the second network node when the determined average number of UEs in RRC INACTIVE state is less than or less than or equal to a threshold.

[0045] In some examples, the threshold compared to the maximum number of UEs in RRC INACTIVE or the threshold compared to the average number of UEs in RRC INACTIVE can be determined in several ways. For example, the threshold can be specified in a specification, e.g., NR, the threshold can be configured to the first network node (e.g., gNB / eNB) from the second network node (e.g., CN, TEC, etc.), or the threshold can be provided from the first network node to the second network node (e.g., predetermined interval determined by gNB / eNB or second network node).

[0046] Based on the comparison of the measured values and the corresponding threshold, the node can report information to the second network node. The information can include the maximum and / or average number of UEs in RRC INACTIVE state, time information associated with when the measurements were collected, and a corresponding identifier of the measurement granularity (e.g., physical cell ID for each cell measurement).

[0047] In some examples, the node can perform the measurements in several ways. For example, in one approach, the node can perform measurements per RAN-based notification area, while in another approach, the node can perform measurements per cell. With respect to the measurements performed per RAN-based notification area, the node can determine the average number of UEs in 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 a predefined interval and determine the average value across RAN-based notification areas. The node can also determine the maximum number of UEs in RRC INACTIVE state during each granularity period of each RAN-based notification area. The node can determine the number of UEs in 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.

[0048] With respect to the measurements performed per cell, after RRC connection suspension, the UE can no longer be connected to the cell. However, the last serving cell will still store the UE context. Thus, an alternative approach to performing per cell measurements can be that the UE in RRC INACTIVE state belongs to the last serving cell. Or in another alternative, the inactive UE is considered to “belong” to the cell where the UE was released from RRC CONNECTED state to RRC INACTIVE state. Or in another example, the UE in RRC INACTIVE state is considered to “belong” to the cell that stores its context. The average number of UEs in RRC INACTIVE state provides the average number of UEs in RRC INACTIVE state during each granularity period of each cell. The node can sample the number of users in RRC INACTIVE state per cell at a predefined interval, where the UE in RRC INACTIVE state is considered to belong to the last serving cell. The node can then determine the average number of UEs in RRC INACTIVE state across all cells.

[0049] The maximum number of UEs in RRC INACTIVE state per cell provides the maximum number of UEs in RRC INACTIVE state per cell per granularity period. Similar to determining the average, the node can determine the maximum by selecting the maximum number of UEs in RRC INACTIVE state across the cells. In some examples, the node can also determine a percentage of UEs in RRC INACTIVE state within the cell during each granularity period. The node can determine the percentage based on a ratio of the average number of UEs in RRC INACTIVE state to a sum of the average number of UEs in RRC INACTIVE state and the average number of UEs in RRC CONNECTED state.

[0050] In some examples, the node can determine maximums and averages in granularities other than the per-cell measurements described above. For example, the node can determine averages and maximums based on network slices, which are logical networks that serve particular traffic or customer needs. In some such examples, the node can determine the maximums and averages based on values determined across multiple network slices. In some other examples, the node can determine maximums and averages across multiple public land mobile networks (PLMNs). In some other examples, the node can measure maximums and averages based on non-public network (NPN) IDs. For example, the node can determine the number of UEs in RRC INACTIVE state per NPN, which can be identified by one or more of an NPN ID, a CAG ID (where CAG indicates a closed access group), or a PLMN ID. In some embodiments, the node can determine averages and maximums over various combinations of contexts. For example, the node can determine averages and maximums 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, or for each cell in each RAN notification area, or for each RAN notification area in each PLMN.

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

[0052] Average duration of UE staying in inactive state

[0053] In some examples, the parameter measured by the node can include an average duration of time that the UE is in an inactive state. This measurement can provide an average duration of time that the UE stays in the RRC INACTIVE state during each granularity period for each cell or each RAN-based notification area. Figure 4 An example timing diagram 400 depicting various UE durations of stay in an inactive state is shown. Specifically, the 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 ti and leaves the RRC INACTIVE state at time ti. 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 an observation period. It should be understood that, Figure 4 The times described in the middle are examples only and the times can vary based on implementation.

[0054] Based on the times that the UEs enter and leave their respective RRC INACTIVE states, the node can determine an average amount of time that the UEs stay in the RRC INACTIVE state. In one approach, the node can determine the average by determining the sum of the durations of stay in the RRC INACTIVE state for those UEs that leave the RRC INACTIVE state during the observation period divided by the total number of UEs that leave the RRC INACTIVE state during the observation period. From Figure 4 As can be seen, UE1, UE2, UE4, and UE5 are UEs that leave their respective RRC INACTIVE states during the observation time (T1 to T2). Thus, the average time can equal ((ti - ti) + (t2 - t2) + (t4 - t4) + (t5 - t5)) / 4.

[0055] In another approach, the node can determine the average amount of time that UEs stay in RRC INACTIVE state by determining the sum of the durations that those UEs that both enter and exit the RRC INACTIVE state during the observation period stay in the RRC INACTIVE state divided by the total number of UEs that both enter and exit their respective RRC INACTIVE state during the observation period. As shown in Figure 4 , UEs 2, 4, and 5 are the only UEs that both enter and exit the respective RRC INACTIVE state during the observation period (T1 to T2). Thus, the average time can equal ((t2’-t2) + (t4’-t4) + (t5’-t5)) / 3.

[0056] In another approach, the node can determine the average amount of time that UEs stay in RRC INACTIVE state by determining the sum of the durations that stay in the RRC INACTIVE state during the observation period within the RAN-based notification area divided 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 durations that stay 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). Referring again to Figure 4 , the average time can equal ((t1’-T1) + (t2’-t2) + (T2-t3) + (t4’-t4) + (t5’-t5) + (T2-T1)) / 6.

[0057] In some examples, the parameters measured by the node can include the durations that UEs are in an inactive state at each RAN-based notification area. In some embodiments, an inactive UE can 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 counting of the duration that the UE stays in the RRC INACTIVE state continues. In some examples, the source cell will provide the target cell with the time span, i.e., the duration that the UE is in the RRC INACTIVE state. The target cell can continue counting the duration on top of the received time span if the UE remains in the RRC INACTIVE state. In another example, the duration can be considered to continue if the RRC resume procedure is initiated only for the purpose of RAN notification area update. In some examples, the source cell will provide 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.

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

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

[0060] In some embodiments, the node can measure the durations as discussed above on a per-cell basis of the wireless communication network. The cell to which the UE belongs can be determined by the cell ID associated with the UE. Or in another alternative, the UE is considered to belong to the cell from which the UE was released from RRC CONNECTED state to RRC INACTIVE state. Further, the UE in RRC INACTIVE state can be considered to belong to the last serving cell. Or in another example, the UE in RRC INACTIVE state is considered to “belong” to the cell that stores its AS context. The node can also measure the durations discussed above on a per network slice basis, where a network slice is a logical network that serves a particular traffic or customer need. The node can collect and / or report the number of UEs in RRC INACTIVE state per network slice (e.g., for each network slice, or for one or more particular network slices). The node can also measure the durations discussed above on a per PLMN basis. For example, the node can collect and / or report the number of UEs in RRC INACTIVE state per PLMN. The node can also measure the durations discussed above on a per NPN ID basis. For example, the node can collect and / or report the number of UEs in RRC INACTIVE state per non-public network, which can be identified by a NPN ID, a CAG ID, or any other combination of a PLMN ID and a NPN ID, a PLMN ID and a CAG ID, or a NPN ID, a CAG ID, and a PLMN ID. The node can make the duration measurements 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 can include a timestamp indicating when the UE entered the RRC INACTIVE state. The node can then utilize the timestamp to determine the duration for which the UE remained in the RRC INACTIVE state.

[0061] The node can report the measured values discussed above to the second network node when one or more conditions are met. For example, the node can report the measurement results to the second network node based on determining that the average duration of UEs staying in the RRC INACTIVE state is less than or equal to a predefined threshold value. In some examples, the node can report the measurement results to the second network node based on determining that the number of UEs staying in the RRC INACTIVE state for a duration less than or equal to a threshold time period is less than or equal to a threshold number. In some examples, the node can report the measurement results to the second network node based on determining that the percentage of UEs staying in the RRC INACTIVE state for a duration less than or equal to a threshold time period is less than or equal to a threshold percentage value.

[0062] The node can report the measured durations and additional information to the second network node. For example, the report can include the average duration of UEs staying in the RRC INACTIVE state, the number of UEs staying in the RRC INACTIVE state for a duration less than or equal to a threshold duration value, the percentage of UEs staying in the RRC INACTIVE state for a duration less than or equal to a threshold duration value, time information when the node collected the measurement values, and corresponding identifiers of the measurement granularity (e.g., physical cell IDs for each cell measurement).

[0063] The threshold values, such as the threshold duration value, can be specified in network specifications, or can be configured to the gNB / eNB from the CN, or can be provided to the CN from the gNB / eNB.

[0064] Number of state transitions per granularity period

[0065] Figure 5 An example state diagram 500 representing state machines and state transitions in NR and EUTRA is shown. The node can measure parameters such as state transitions of UEs and report these state transitions to the second network node. Specifically, in one example, the node can measure a total number of transitions from the RRC INACTIVE / RRC IDLE state to the RRC CONNECTED state per granularity period per cell. The node can determine the total number based on a sum of the number of RRCSetupComplete and RRCResumeComplete messages received from each cell during each granularity period. The RRCSetupComplete message indicates a successful completion of RRC connection setup, and the RRCResumeComplete message indicates a successful completion of RRC connection resume. The node can also determine the total number based on a difference in the number of UEs in the RRC CONNECTED state per cell in two consecutive granularity periods.

[0066] In another example, the node can measure a total number of transitions from the RRC CONNECTED state to the RRC INACTIVE state per granular period per cell. In one example, the node can determine a total number of RRC INACTIVE UEs per RAN-based notification area. That is, the node can determine a difference between a number of UEs in the RRC INACTIVE state per RAN-based notification area during two consecutive granular periods. In another example, the node can determine a total number of RRC INACTIVE UEs per cell. That is, the node can determine a difference between a number of UEs in the RRC INACTIVE state per cell during two consecutive granular periods.

[0067] In yet another example, the node can measure a total number of transitions from the RRC INACTIVE state to the RRC IDLE state. A UE transitions from the RRC INACTIVE state to the RRC IDLE state by receiving an RRCRelease message without suspension or receiving an RRCReject message from the network. In one example, the node can determine a total number of transitions per RAN-based notification area. That is, the node can determine a sum of a number of RRCRelease messages transmitted per RAN-based notification area during each granular period that are configured without suspension and RRCReject messages that are scrambled with a Temporary Cell Radio Network Temporary Identifier (TC-RNTI). In another example, the node can determine a total number of transitions per cell. That is, the node can determine a sum of a number of RRCRelease messages transmitted per cell during each granular period that are configured without suspension and RRCReject messages that are scrambled with a TC-RNTI.

[0068] In some embodiments, the node can report the total number of transitions discussed above to the second network node. In some embodiments, the node can report the total number of transitions discussed above to the second network node based on a result of a comparison of the total number with a corresponding threshold value. For example, the node can report the total number of transitions 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) the threshold value.

[0069] On-demand system information

[0070] In one embodiment, the node can measure system information and report it to the second network node. System information (SI) is divided into a master information block (MIB) and a number of system information blocks (SIBs). The MIB is always transmitted on the broadcast channel (BCH) periodically, which contains information needed to decode SIB1. SIB1 is transmitted on the downlink shared channel (DL-SCH) periodically, which carries basic information for cell (re)selection, access control, RACH resource configuration, etc. SIBs other than SIB1 are carried in SystemInformation (SI) messages, which are transmitted on the DL-SCH. Only SIBs with the same periodicity can be mapped to the same SI message. Each SI message is transmitted within a time-domain window that occurs periodically (called SI window with the same length for all SI messages). Each SI message is associated with a SI window, and the SI windows for different SI messages do not overlap. That is, within one SI window, only the corresponding SI message is transmitted. The UE can request system information other than MIB and SIB1 according to an on-demand SI acquisition procedure, which includes a MSG1 -based SI request procedure (if dedicated resources are configured) or a MSG3 -based SI request procedure (if dedicated resources are not configured). After receiving the preamble for the SI request, the node or network can broadcast the requested system information. Since the mapping of 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.

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

[0072] In another example, if the SIB is set to be area specific, the node can determine the number of SI requests received for each SI message in each system information area. A system information area is an area in which an area specific SIB applies. In some embodiments, a system information area can consist of one or more cells and is identified by a systemInformationAreaID. The systemInformationAreaID can be unique in a single PLMN. In one approach, the node can determine the number of SI requests received for each SI message during each granularity period for each system information area. In another approach, the node can determine the number of SI requests received for each SIB during each granularity period for each cell of each system information area. In yet another approach, the node can determine the percentage of transmission time for one SIB, which is defined as the actual transmission occasions / potential transmission occasions during a granularity period.

[0073] The node can report the measurement information to the managing node based on the comparison result between the number of SI or SIB discussed above and the corresponding threshold. 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, where x is the index of SI in this example. 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, where x is the index of SIB in this example. In another example, if the percentage of transmission time for one 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. The threshold can be specified in the specification of NR, or the threshold can be configured to the gNB / eNB from the core network (CN), or the threshold can be provided from the gNB / eNB to the CN (e.g., the predetermined interval is determined by the gNB / eNB or the second network node).

[0074] The report provided to the second network node can 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 one SIB message, the time information when the measurement result is collected, and the cell ID or system information area ID in which the measurement result is collected, where x is the index of SI or SIB in this example.

[0075] Dedicated preamble for beam failure recovery (BFR) per beam per cell

[0076] The node can also determine the number of dedicated preambles reserved by BFRs received by each beam during each granularity period. In addition, the node can count the number of dedicated preambles reserved by BFRs received by each cell or each beam during each granularity period. The node can compare the number determined above with a corresponding threshold, and based on the result of the comparison, the node can provide the value of the number, and / or the beam index, and / or the cell ID, and / or the time information when the measurement is performed, to the second network node.

[0077] Number of preambles transmitted per cell for different RACH types

[0078] 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 for two-step RACH by each cell during each granularity period. In another example, the node can measure the number of preambles for four-step RACH by each cell during each granularity period. In another example, the node can determine the ratio of the number of preambles for two-step RACH to the number of preambles for four-step RACH by each cell during each granularity period. In yet another method, the node can determine the percentage of the number of preambles for two-step RACH out of the total number of preambles received by each cell during each granularity period. In yet another method, the node can determine the percentage of the number of preambles for four-step RACH out of the total number of preambles received by each cell during each granularity period.

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

[0080] In another example, during each granularity period of each cell, the number of preambles for 2-step RACH and 4-step RACH can be measured in a supplemental uplink carrier (SUL) and a normal uplink carrier (NUL), respectively. For example, the node can measure the number of preambles for 2-step RACH in NUL during each granularity period of each cell. In another example, the node can measure the number of preambles for 2-step RACH in SUL during each granularity period of each cell. In another example, the node can measure the number of preambles for 4-step RACH in NUL during each granularity period of each cell. In another example, the node can measure the number of preambles for 4-step RACH in SUL during each granularity period of each cell.

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

[0082] II. Measurements by the UE

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

[0084] The UE 600 can indicate the availability of one or more measurement reports in step 1 (604). For example, the reports can include a RACH success report, a RACH failure report, an RLF report, and the like. Each of these measurement reports is discussed below.

[0085] In some embodiments, the first network node can determine more parameters from the information reported from the UE side. In some embodiments, the first network node can periodically report the measured parameters to the second network node. The reporting period can be specified in the specification, or configured to the first network node (e.g., gNB / eNB) from the second network node (e.g., CN), 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 can report the measured parameters to the second network node if the measured parameters are below, or below equal to, or above, or above equal to, a configured threshold. The threshold can be specified in the specification, or configured to the first network node (e.g., gNB / eNB) from the second network node (e.g., CN), or configured by the first network node and provided to the second network node from the first network node.

[0086] RACH success report

[0087] The RACH success report can store measurements related to the UE 600 successfully completing RACH. In some embodiments, the RACH success report can not include measurements related to the first successful RACH, as these measurements can be included in the RLF report. In some examples, the RACH report can include information about one or more triggering events that triggered the measurements performed by the UE 600. The triggering events can include, for example, at least one of: initial access initiated in RRC_IDLE state, RRC connection re-establishment procedure, arrival of DL or UL data during RRC_CONNECTED state when the UL synchronization status is “non-synchronized”, arrival of UL data during RRC_CONNECTED state but no PUCCH resource for SR is available, SR failure, RRC requests synchronization reconfiguration (e.g., during handover), transition from RRC_INACTIVE state, establishment of time synchronization at SCell addition, request for other SI or beam failure recovery.

[0088] The RACH report can also include a connection failure time indicating the time elapsed since the last handover initialization to the connection failure. The RACH report can also include a time since failure indicating the time elapsed since the connection setup failure. The RACH report can also include a list of beam indices of beams the UE has attempted the RACH procedure on. The RACH report can also include a beam type (e.g., SSB or CSI-RS) of each beam the UE has attempted the RACH procedure on. The RACH report can additionally include a number of preambles transmitted for each beam the UE made a RACH attempt on. If the RACH was triggered by a BFR, the RACH report can also include an index of the beam where the BFR occurred. If the RACH was triggered by a BFR, the RACH report can also include a BFR timestamp indicating the absolute time when the BFR occurred. The RACH report can also include a parameter contentionDetected indicating that contention was detected for at least one transmitted preamble. The RACH report can also include a parameter maxTxPowerReached that can determine whether a maximum power level was used for the preamble of the last transmission. The RACH report can also include a success timestamp indicating the absolute time when the RACH was successfully completed. The RACH report can also include a RACH type indicator that can select between two-step and four-step. In some examples, the RACH type can be determined by the RACH type of the first RACH attempt. In another example, the RACH type can be determined by the RACH type of the latest RACH attempt. The RACH report can also include a number of four-step RACH attempts in the RACH procedure. The RACH report can also include a number of two-step RACH attempts in the RACH procedure. The RACH report can also include a fallback indication that can be set to true if at least one fallback occurred in the RACH procedure. The RACH report can also include a number of preambles transmitted over SUL and / or a number of preambles transmitted over NUL. The above list of items in the RACH report is not exhaustive, and the RACH report can include a combination of any of the above items and any additional measurements performed by the UE.

[0089] RACH failure report

[0090] In the case of a RACH failure, the UE can declare a radio link failure (RLF) and can select a suitable cell to reestablish the RRC connection by initiating a RACH. RACH related measurements performed by the UE prior to declaring the RLF can be stored in a RACH failure report. On the other hand, RLF related measurements, including RACH related measurements during RRC connection reestablishment, can be stored in a RLF report. In some embodiments, the RACH failure report can be included in the RLF report.

[0091] The RACH failure report can include information about one or more triggering events that triggered the measurements performed by the UE. For example, the triggering events can include an initial access initiated in RRC_IDLE state, an RRC connection re-establishment procedure, arrival of DL or UL data during RRC_CONNECTED state when the UL synchronization status is "non-synchronized", arrival of UL data during RRC_CONNECTED state but no PUCCH resource available for SR, SR failure, RRC request for synchronization reconfiguration (e.g., during handover), transition from RRC_INACTIVE state, establishment time synchronization at SCell addition, request for other SI, and beam failure recovery event.

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

[0093] RLF report

[0094] RLF report can include measurements related to radio link failure before a successful RRC connection is established. The RLF report can include the RACH failure report discussed above. The RLF report can also include a BFR indication, e.g., when the RLF is triggered by an unsuccessful completion of BFR. The RLF report can also include a C-RNTI, which indicates the C-RNTI used in the PCell at the time of detecting the radio link failure or the C-RNTI used in the source PCell at the time of handover failure. The RLF report can also include a connection failure type, which can indicate whether the connection failure is due to radio link failure or handover failure. The RLF report can also include a PCell ID of the failure, which can indicate the PCell at which the RLF is detected or the target PCell of the handover failure. The UE can set an E-UTRA absolute radio frequency channel number (EARFCN) according to the frequency band used for transmission / reception at the time of the failure. The RLF report can also include a cell ID of the failure, which can indicate the cell of the connection establishment failure. The RLF report can also include a previous PCell ID, which can indicate the source PCell of the last handover (the source PCell at the time of receiving the last RRC connection reconfiguration message including mobilityControlInfo). The RLF report can also include a reestablishment cell ID, which can indicate the cell in which the reestablishment attempt is made after the connection failure. The RLF report can also include an RLF cause to indicate the cause of the last detected radio link failure. In the case of handover failure information report (i.e., connectionFailureType is set to HOF), the UE can set this field to any value. The RLF report can also include an RLF timestamp, which indicates the absolute time at which the RLF occurred. The RLF report can also include RLF location information, which indicates the location at which the RLF occurred. The RLF report can also include a time of connection failure, which indicates the time elapsed from the last handover initialization to the connection failure. The RLF report can also include a time since failure, which indicates the time elapsed since the connection (establishment) failure. The RLF report can also include a list of beam indices of the beams in which the UE has attempted the RACH procedure. The RLF report can also include a beam type (e.g., SSB or CSI-RS) of each beam in which the UE has attempted the RACH procedure. The RLF report can also include a number of preambles transmitted for each beam in which the UE has attempted the RACH procedure. The RLF report can also include contentionDetected, which can indicate that contention was detected for at least one transmitted preamble. The RLF report can also include maxTxPowerReached, which can indicate whether the maximum power level was used for the last transmitted preamble. The RLF report can also include a success timestamp, which indicates the absolute time at which the RACH is successfully completed.The RLF report can further include information included in a RACH failure report, or include a RACH failure report, where the RACH failure report includes information of the latest failed RACH procedure prior to reestablishing or establishing an RRC connection. The RLF report can further include information included in a RACH success report, or include a RACH success report, where the RACH success report includes information of the RACH procedure initiated for successfully reestablishing or establishing an RRC connection after the RLF. The above list of items in the RLF report is not exhaustive, and the RLF report can include a combination of any of the above items and any additional measurements performed by the UE.

[0095] Other RACH related measurements

[0096] In addition to the measurements performed by the UE, the node or base station receiving the measurement information from the UE can determine additional measurement parameters based on the received measurement report. For example, the node can determine a success rate of two-step RACH for each cell during each granularity period. The success rate can be determined based on a ratio of the total number of two-step RACH procedures that successfully completed to the total number of two-step RACH procedures initiated by each cell during each granularity period. Each initiated RACH procedure can only be counted once regardless of the total number of transmitted preambles.

[0097] In some examples, the node can also determine a success rate of two-step RACH without fallback for each cell during each granularity period. The value can be determined based on a ratio of the total number of two-step RACH procedures that successfully completed without a fallback occurring during the RACH procedure to the total number of two-step RACH procedures initiated by each cell during each granularity period. Each initiated RACH procedure can only be counted once regardless of the total number of transmitted preambles.

[0098] In some examples, the node can further determine a success rate of four-step RACH procedures for each cell during each granularity period. The success rate can be determined based on a ratio of the total number of four-step RACH procedures that successfully completed to the total number of four-step RACH procedures initiated by each cell during each granularity period. Each initiated RACH procedure can only be counted once regardless of the total number of transmitted preambles.

[0099] In some examples, the node can also determine the number of fallbacks per cell during each granularity period. This number can be determined based on the number of two-step RACH procedures initiated per cell during each granularity period that occurred with a fallback. In another example, the node can also determine the likelihood of a fallback 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 during each granularity period that occurred with a fallback to the total number of two-step RACH procedures initiated per cell during each granularity period. Each initiated RACH procedure can only be counted once regardless of the total number of transmitted preambles.

[0100] For the above measurements, a threshold can be configured to make a comparison, and if the measurement value is higher than, higher than or equal to, lower than, lower than or equal to the threshold, the node will be triggered to report the result to the second node or CN. The threshold can be specified in the specification of NR, or the threshold can be configured from the core network (CN) to the gNB / eNB, or the threshold can be provided from the gNB / eNB to the CN (e.g., a predetermined interval is determined by the gNB / eNB or the second node).

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

[0102] Beam related measurements

[0103] In some examples, the node can determine the value of one or more parameters based on information and reports received from the UE. In some examples, the node can determine the number of BFRs per beam during each granularity period. In one approach, this number of BFRs can be obtained as the total number of RACH failures (triggering event is “BFR”) plus the total number of successful RACH (triggering event is “BFR”) per beam during each granularity period, which can be calculated from reports collected from the UE side. In another approach, each time a BFR occurs, the UE can indicate the occurrence of the BFR and the beam index to the node by means of sending an encoded signal over PUCCH. The node can then calculate the total number of BFRs that occurred per beam during each granularity period from the received information.

[0104] In another example, the node can determine the average number of attempts required to successfully complete a BFR for each beam. This average number is obtained as the sum of the number of preambles sent by each beam for which the UE has attempted a RACH procedure (where the triggering event is “BFR”) in the RACH success reports collected per granularity period divided by the number of RACH success reports collected per granularity period (where the triggering event is “BFR”).

[0105] In yet another example, the node can determine the average number of attempts needed to successfully recover connection after triggering BFR for each beam. The number can be obtained as the sum of the number of preambles sent for each beam in RACH success reports and RACH failure reports (triggering event is BFR) and in RLF reports (where RACH failure reports are included, collected per granularity period), divided by the sum of the number of RACH success reports, RACH failure reports and RLF reports (where RACH failure reports are included, collected per granularity period).

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

[0107] In another approach, the node can determine the average time needed to successfully recover RRC connection after triggering BFR for each cell. The average time can be obtained as the sum of the duration of successful recovery of RRC connection per granularity period per cell divided by the number of RACH success reports and RLF reports collected per granularity period per cell, where the duration of RRC connection successful recovery includes the duration of RACH successful completion in RACH success reports with the triggering event as BFR and the duration of RRC successful recovery in RLF reports containing the indication of BFR. The duration of RRC successful recovery can be obtained as the time difference between the successful timestamp and the BFR timestamp in the RACH failure report.

[0108] How the UE decides whether to perform measurements

[0109] As discussed above with respect to Figure 6 In step 1, the UE indicates the availability of the report to the gNB. However, the procedure for the UE to perform the measurements for inclusion in the report can be based on certain conditions. In a first aspect, the UE capable of performing the measurements can always perform the supported measurements in response to a set of triggering events. For example, for RLF related measurements, the UE can always measure the related measurements upon detecting RLF and store the related measurements in memory for reporting to the gNB.

[0110] In a second aspect, the UE can perform the measurements according to the measurement configuration received from the network.

[0111] In a third aspect, the UE can perform the measurements upon triggering by some event, where the triggering event can be at least one of: initiation of a random access procedure, RLF, and events A1 to A6 and events B1 to B2 defined in the protocol. These events are also described in TS 38 331 section 5.5.4, which can refer to event A1 : serving cell quality better than a threshold, event A2: serving cell quality worse than a threshold, event A3: neighbor quality better than SpCell by a certain threshold, event A4: neighbor becomes better than a threshold, event A5: SpCell becomes worse than threshold 1 and neighbor becomes better than threshold 2, event A6: neighbor serving quality better than SCell by a certain threshold, event B1 : cross-RAT neighbor becomes better than a threshold, and event B2: PCell becomes worse than threshold 1 and cross-RAT neighbor becomes better than threshold 2.

[0112] In a fourth aspect, the UE can perform the measurements under the control of the network. In one example, the measurement list can be predefined or configured by the network. The configuration can include, for example, “L2MeasRequest_i”, 1 <= i <= 2 Num_of_MeasType -1, where Num_of_MeasType is equal to the total number of defined measurement types. Each measurement list (including a list of different measurement types) can be used to enable one or more measurement types that can be performed. Each type of measurement can include a list of measurement quantities. For example, if there are RLF-related measurements, RACH-related measurements, and mobility-related measurements, the requested measurement list can be considered as:

[0113] L2MeasRequest_1 : RLF-related measurements;

[0114] L2MeasRequest_2 : RACH-related measurements;

[0115] L2MeasRequest_3 : mobility-related measurements;

[0116] L2MeasRequest_4 : RLF-related measurements, RACH-related measurements;

[0117] L2MeasRequest_5 : RLF-related measurements, mobility-related measurements;

[0118] L2MeasRequest_6 : mobility-related measurements, RACH-related measurements;

[0119] L2MeasRequest_7 : RLF-related measurements, RACH-related measurements, mobility-related measurements.

[0120] The node or network can broadcast the requested list of measurements to be performed by the UE or can be delivered in system information or through RRC signaling. For example, if the UE receives a reconfiguration message including L2MeasRequest_1, the UE can perform RLF-related measurements if an RLF occurs and follows the procedure as shown in the general procedure section.

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

[0122] Any combination of the above aspects can also be utilized. 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, while the actual time for performing the measurement is based on the time when the measurement configuration or trigger event occurs.

[0123] How the UE indicates the availability of measurements to be acquired

[0124] Reference Figure 6 Referring to Step 1 shown in FIG. 1, the following discusses conditions that the UE can indicate to the gNB for the availability of one or more reports. In NR, RACH resources (e.g., RACH occasions and preambles) are closely related to beams, and some measurements are also performed at the beam level. Introducing beam-level measurements helps better manage beams and configure resources. Due to changes in the network environment, user mobility, interference from other users, etc., beam quality and correspondence are constantly changing, so it is helpful to find an effective way to report beam-related measurement results to ensure the effectiveness of the measurements, or in other words, to keep the measurement results up to date. Upon detecting a beam failure, the UE can trigger a BFR procedure by initiating a RACH procedure to try to find a suitable beam to perform BFR.

[0125] The availability of the report can be indicated to the node in various ways. In a first approach, the indication or the list of indications can be sent through an RRC message (e.g., RRCSetupComplete message). In some examples, each indication is used to indicate the availability of a specific type of measurement report, e.g., a "1" in the indication means that the corresponding report is available, and a "0" in the indication means that the corresponding measurement report is not available. Or in another example, a "1" in the indication means that the corresponding report is available, and a "0" in the indication means that the corresponding measurement report is not available. In a second approach, the indication or the list of indications can be sent through a signal transmitted in PUCCH. In a third approach, the indication can be sent using a MAC control element (MAC-CE). For example, the message can include a "UE Info Available MAC CE" identified by a MAC subheader with LCID 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 reception of the 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. A "0" indicates that the corresponding measurement report is not available, and a "1" indicates that the corresponding measurement is available. The mapping of the 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 set to reserved. Where the reserved bits can always be set to "0". Any combination of the above four approaches can also be used.

[0126] In some embodiments, after successful completion of RACH, the relevant measurements can be stored in a RACH success report. If the payload part of Msg3 for four-step RACH or Msg1 for two-step RACH contains RRC message, the subsequent RRC message (e.g., RRCResumeComplete, RRCSetupComplete, RRCReestablishmentComplete, or RRCReconfigurationComplete) can contain an information element (IE) (e.g., “RACHSuccess-InfoAvailability”) to indicate the availability of the RACH success report. For example, after completion of RRC connection setup, the UE can indicate that the RACH success report is available by setting “RACHSuccess-InfoAvailability” to true in RRCSetupComplete. In another example, the UE can indicate the availability of the RACH success report as soon as possible after RACH success completion using a signal similar to scheduling request (SR) transmitted in PUCCH, or by transmitting a MAC CE (e.g., “RACH Success Info Available MAC CE”) to the base station.

[0127] In instances where RACH failure occurs, the UE can claim radio link failure (RLF) and attempt to select a suitable cell to reestablish RRC connection by initiating RACH. RACH related measurements can be stored in a RACH failure report, and other RLF related measurements can also be stored in a RLF report. In addition, 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 resume, or handover, which can be done by including an IE in the RRC message, e.g., “rlf-InfoAvailable” in RRCResumeComplete, RRCSetupComplete, RRCReestablishmentComplete, or RRCReconfigurationComplete. In addition, an IE, e.g., “RACHFailure-InfoAvailability,” can be included in RRCResumeComplete, RRCSetupComplete, RRCReestablishmentComplete, or RRCReconfigurationComplete to indicate the availability of the RACH failure report.

[0128] When to clear stored measurement results

[0129] In relation to step 3 (cf. above Figure 6 ), the UE can delete the report from memory under certain conditions. For example, in a first approach, the UE can delete the measurement results immediately after reporting the report to the node. In a second approach, the UE can delete the measurement results from memory after receiving a positive acknowledgement from the node that the measurement report was successfully received. In a third approach, the UE can continue to store the measurement report until the next measurement is triggered. In a fourth approach, different validity periods can be configured for different measurement quantities. If a measurement result has not been taken and the validity period has expired, the measurement result will be deleted. The validity period can be configured by the network, or by the CN, or by the second network node, or pre-defined in the protocol. Furthermore, any combination of the above four approaches can be utilized to determine when to delete the measurement report at the UE.

[0130] While various embodiments of the present solution have been described above, it should be understood that they have been presented by way of example only, and not limitation. Likewise, the various figures can depict example architectures or configurations, which provide illustration of the various features and functionality described herein. It should be readily appreciated that a vast number of permutations and combinations of the features described herein are possible and within the scope of the present solution. Additionally, any one or more features of one embodiment can be combined with any one or more features of another embodiment. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above described embodiments.

[0131] It should also be understood that any reference to an element in the singular has no intention to limit the implementation to a single element unless the context clearly indicates otherwise. Rather, such references are typically intended to mean one or more elements. By way of example, a component can include one or more processors, controllers, or the like. It should also be understood that where the terms "comprising", "including", containing", etc. are used, they are used in the sense of "including but not limited to", and not in the sense of "consisting only of" or "consisting exclusively of", unless specifically indicated otherwise.

[0132] Further, one of ordinary skill in the art will appreciate that any of the various technical features described herein can be represented using any of a number of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols, which can be referenced throughout the above description, may

[0133] Those of ordinary skill in the art will further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two), firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as "software" or a "software module"), or any combination of these techniques, as desired. To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality, without reference to the particular manner in which they are implemented. The functionality of these components, blocks, modules, circuits and steps can be implemented in a variety of ways, as desired. The particular methodology of implementing these components, blocks, modules, circuits and steps is not important to the aspects of the disclosure, and therefore will not be described in detail herein. It is noted that the aspects of the disclosure can be implemented in software and / or firmware in combination with hardware and / or firmware, as desired. For example, one or more illustrative components, blocks, modules, circuits and steps can be implemented in software and / or firmware in combination with hardware and / or firmware, as desired.

[0134] Furthermore, those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, devices, components and circuits described herein can be implemented or performed with an integrated circuit (IC), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The logic blocks, modules and circuits can further include antennas and / or transceivers to communicate with various components within a network or within a device. The general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. The processor can also be implemented as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0135] If functions are implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Therefore, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program or code from one place to another. Storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, functional computer- readable media that stores program code in a modulated data signal, such as carrier waves or other transport mechanism, can be utilized to communicate a desired program code (e.g., instructions) or software in the form of data packets or data signals. Combinations of the above should also be included within the scope of computer-readable media.

[0136] In this document, the term "module" as used herein, refers to software, firmware, hardware, and any combination of these elements that is used to perform the associated functions described herein. Additionally, the various modules described herein can be comprised of programming means for implementing the associated functions with the various embodiments. Furthermore, the various modules can be combined or integrated into a single module, or further separated and distributed among various modules. In addition, for purposes of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skill in the art, two or more modules can be combined to form a single module that performs the associated functions according to embodiments of the present solution.

[0137] Additionally, memory or other storage devices and communication components can be employed in embodiments of the present solution. As will be apparent, the description above has described embodiments of the present solution with reference to different functional units and processors. However, one of ordinary skill in the art will readily appreciate that the functionality of two or more such units can be combined into a single unit; or the functionality of one unit can be distributed among two or more units. The foregoing approach provides numerous benefits, including reduced costs and improved efficiency.

[0138] Various modifications to the implementations described in this disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Thus, the disclosure is not intended to be limited to the implementations shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein and made apparent to others skilled in the art by the teachings herein. The scope of the disclosure, therefore, is to be determined solely by the following claims, including any equivalents.

Claims

1. A wireless communication method, comprising: The first wireless communication node measures at least one parameter related to wireless communication devices in the wireless communication network, wherein the wireless communication devices include at least one user equipment (UE) that remains in an inactive state, wherein the at least one parameter includes a maximum or average number of wireless communication devices that remain in an inactive state, wherein when the UE remains in the inactive state, the UE belongs to a cell that stores context related to the UE. The first wireless communication node reports the at least one parameter to a second wireless communication node associated with the wireless communication network, wherein the first wireless communication node includes a base station and the second wireless communication node includes a core network node.

2. The method according to claim 1, comprising: The first wireless communication node measures the at least one parameter during each granular period of each cell in the wireless communication network: The first wireless communication node measures the average number of the at least one UE based on network slices; The first wireless communication node measures the maximum number of the at least one UE based on network slices; The first wireless communication node measures the average number of the at least one UE spanning multiple Public Land Mobile Networks (PLMNs); The first wireless communication node measures the maximum number of at least one UE spanning multiple PLMNs; The first wireless communication node measures the average number of the at least one UE based on the non-public network NPN ID; or The first wireless communication node measures the maximum number of the at least one UE based on the NPN ID.

3. The method according to claim 1, comprising: The first wireless communication node measures the at least one parameter during each granular period of each RAN-based notification area in the wireless communication network.

4. The method according to claim 1, wherein, The at least one parameter includes the number of wireless communication devices that remain inactive for a duration less than a configured threshold.

5. The method according to claim 1, wherein, The at least one parameter includes the number of state transitions between at least one of an inactive state and an idle state or a connected state.

6. The method according to claim 1, wherein, The at least one parameter includes the number of system information requests received from the wireless communication device.

7. The method according to claim 1, wherein, The at least one parameter includes a percentage of the transmission time of system information requests received from the wireless communication device.

8. The method according to claim 1, wherein, The at least one parameter includes the total number of dedicated preambles used for beam fault recovery.

9. The method according to claim 1, wherein, The at least one parameter includes the number of preambles used in the random access channel procedure.

10. A computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1-9.

11. A computing device comprising a processor and a memory, wherein, The processor is configured to read code from the memory and implement the method according to any one of claims 1-9.

Images