Title - METHOD FOR USER EQUIPMENT TO REPORT LINK FAILURES IN A WIRELESS NETWORK, METHOD FOR A RADIO NETWORK NODE IN A WIRELESS NETWORK TO RECEIVE FAILURE REPORTS FROM USER EQUIPMENT, AND SAID USER EQUIPMENT AND RADIO NETWORK NODES

Abstract

Methods for a user equipment (UE) to report link failures in a wireless network. These methods include, after a link failure (e.g., radio link failure or handover failure) and a failed connection re-establishment in a first public land mobile network (PLMN), connecting to a first cell in the wireless network. These methods include sending a failure report to a radio network node (RNN) in the wireless network, which includes an indication of whether the first cell is associated with the first PLMN. Different forms and / or contents of the indication are disclosed. Also disclosed are supplementary methods for an RNN, as well as UEs and RNNs configured to perform such methods.

Description

This disclosure relates generally to wireless communication networks and more specifically to improved techniques for reporting link failures (e.g., radio link failures, handover failures, etc.) experienced by user equipment (UE) on such networks. BACKGROUND Long-Term Evolution (LTE) is a term that encompasses fourth-generation (4G) radio access technologies developed under the Third Generation Partnership Project (3GPP) and initially standardized in versions 8 (Rel-8) and 9 (Rel-9), also known as Evolved UTRAN (EUTRAN). LTE targets several licensed frequency bands and is accompanied by improvements in non-radio aspects commonly referred to as System Architecture Evolution (SAE), which includes the Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent versions. Figure 1 shows a general example architecture of a network comprising LTE and SAE. The E-UTRAN 100 includes one or more evolved node Bs (eNBs), such as eNBs 105, 110, and 115, and one or more user equipment (UEs), such as UE 120. As used in the 3GPP standards, “user equipment” or “UE” means any wireless communication device (e.g., a smartphone or computer device) that can communicate with network equipment that complies with the 3GPP standards, including the E-UTRAN as well as the UTRAN and / or GERAN, as the third-generation (“3G”) and second-generation (“2G”) 3GPP RANs are commonly known. As specified by 3GPP, E-UTRAN 100 is responsible for all radio-related functions in the network, including radio carrier control, radio admission control, radio mobility control, scheduling and dynamic allocation of resources to UEs in the uplink and downlink, and the security of communications with UEs. These functions reside in the eNBs, such as eNBs 105, 110, and 115. Each eNB can serve a geographic coverage area that includes one additional cell, including cells 106, 111, and 115, served by eNBs 105, 110, and 115, respectively. 1758931 of 73 The E-UTRAN eNBs communicate with each other via the X2 interface, as shown in Figure 1. The eNBs are also responsible for the E-UTRAN interface with the EPC 130, specifically the S1 interface with the Mobility Management Entity (MME) and the Service Gateway (SGW), collectively shown as MME / S-GWs 134 and 138 in Figure 1. In general, the MME / S-GW handles both the overall control of the user equipment and the data flow between the user equipment and the rest of the EPC. More specifically, the MME processes the signaling protocols (e.g., the control plane) between the UE and the EPC, which are known as non-access layer (NAS) protocols. The S-GW handles all Internet Protocol (IP) data packets (e.g., data or user plane) between the UE and the EPC and serves as a local mobility anchor for data carriers when the UE moves between eNBs, such as eNBs 105, 110, and 115. The EPC 130 can also include a Home Subscriber Server (HSS) 131, which manages user and subscriber-related information. The HSS 131 can also provide support functions for mobility management, call and session configuration, user authentication, and access authorization. The functions of the HSS 131 can be related to the functions of the legacy Home Location Register (HLR) and Authentication Center (AuC). The HSS 131 can also communicate with the MME 134 and 138 via their respective S6a interfaces. In some embodiments, the HSS 131 can communicate with a user data repository (UDR), labeled EPC-UDR 135 in Figure 1, via a Ud interface. The EPC-UDR 135 can store user credentials after they have been encrypted using AuC algorithms. These algorithms are not standardized (i.e., they are vendor-specific), so the encrypted credentials stored in the EPC-UDR 135 are inaccessible to any vendor other than the HSS 131 vendor. Figure 2 illustrates a block diagram of a sample control plane (CP) protocol stack between a UE, an eNB, and an MME. The sample protocol stack includes the physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and radio resource control (RRC) layers between the UE and the eNB. The PHY layer handles how and what features are used to transfer data across the transport channels at the LTE radio interface. The MAC layer provides data transfer services over logical channels and maps the logical channels to the transport channels. 1758931 of 73 transports PHYs and reallocates PHY resources to support these services. The RLC layer provides error detection and / or correction, concatenation, segmentation and reassembly, and reordering of data transferred to or from the upper layers. The PDCP layer provides encryption / decryption and integrity protection for both the CP and the user plane (UP), as well as other UP functions such as header compression. The example protocol stack also includes NAS signaling between the UE and the MME. The RRC layer controls communication between a UE and an eNB on the radio interface, as well as UE mobility between cells in the E-UTRAN. After a user device is powered on, it will be in the RRC_IDLE state until an RRC connection is established with the network, at which point the user device will transition to the RRC_CONNECTED state (for example, when data transfer can occur). The device returns to the RRC_IDLE state when the network connection is released. In the RRC_IDLE state, the UE does not belong to any cell, no RRC context has been established for the UE (for example, in the E-UTRAN), and the UE is out of UL synchronization with the network. Even so, a UE in the RRC_IDLE state is known to the EPC and has an assigned IP address. Additionally, in the RRC_IDLE state, the UE's radio is active on a discontinuous receive (DRX) schedule configured by the upper layers. During active DRX periods (also called "activation durations"), an RRC_IDLE UE receives system information (SI) broadcast by a server cell, performs measurements of neighboring cells to support cell reselection, and monitors an EPC page search channel via an eNB serving the cell in which the UE is camped. A UE must perform a random access (RA) procedure to transition from the RRC_IDLE state to the RRC_CONNECTED state. In the RRC_CONNECTED state, the cell serving the user equipment is known, and an RRC context is established for the user equipment on the serving eNB, enabling communication between the user equipment and the eNB. For example, in the RRC_CONNECTED state, a cell radio network temporary identifier (C-RNTI) is configured—a user equipment identity used for signaling between the user equipment and the network. The fifth generation (“5G”) of cellular systems, also called New Radio (NR), is being standardized within the Third Generation Partnership Project (3GPP). NR has been developed to offer maximum flexibility and 1758931 of 73 supports a wide variety of use cases. These include enhanced mobile broadband (eMBB), machine-type communications (MTC), ultra-reliable low-latency communications (URLLC), and other use cases. 5G / NR technology shares many similarities with fourth-generation LTE. For example, the NR RRC layer includes the RRC_IDLE and RRC_CONNECTED states, but adds another state known as RRC_INACTIVE. In addition to providing coverage through "cells," as in LTE, NR networks also provide coverage through "beams." Generally, a DL "beam" is a coverage area of ​​a reference signal (RS) transmitted by the network that can be measured or monitored by a UE (Environmental Unit). A common mobility procedure for UEs in the RRC_CONNECTED state is the cell handover (HO). A UE hands off from a source or service cell, provided by a source node, to a destination cell provided by a destination node. Generally, for LTE (or NR), the source and destination handover nodes are different eNBs (or gNBs), although intra-node handovers between different cells provided by a single eNB (or gNB) are also possible. Successful handovers allow the user equipment to move across the network coverage area without excessive interruption to data transmission. SYNTHESIS Even so, handovers and other mobility procedures can have several robustness-related problems. A handover failure to a destination cell can cause the user equipment to declare a radio link failure (RLF) in the source cell. A UE records the relevant information at the time of the RLF and subsequently communicates this information to the network through a destination cell to which the user equipment ultimately connects (for example, after the reset). The communicated information may include RRM measurements from several neighboring cells prior to the mobility operation (for example, the handover). In particular, the UE may indicate that it has an RLF report and then send the RLF report at the network's request (for example, by the node serving the UE's new cell).However, there are several problems, issues and / or difficulties for RLF reporting when a UE finally connects to a cell in a second network (e.g., LTE) after declaring RLF in a cell in a first network (e.g., NR). The methods described in this disclosure provide specific improvements for reporting failures in a wireless network, such as 1758931 of 73 providing solutions to overcome example problems summarized above and described in more detail below. The methods for implementing this disclosure include procedures for a UE to report link failures in a wireless network. These example methods might include, after a link failure and a failed attempt to re-establish the connection to a first PLMN, reconnecting to a first cell in the wireless network. These example methods might also include sending a failure report to a radio network node (RNN) in the wireless network, indicating whether the first cell is associated with the first PLMN. In some embodiments, the link failure is an RLF or a handover failure (HOF) declared by the UE in the first PLMN, and the failure report is an RLF report. In some embodiments, the link failure occurred in a second cell associated with the first PLMN, and the restoration of the failed connection occurred in a third cell associated with the first PLMN. In some embodiments, these example methods may also include, in response to a link failure, storing a list of PLMN identifiers associated with a cell where the link failure occurred, including an identifier of the first PLMN. In some of these embodiments, the list of PLMN identifiers is included in the failure report. In some of these embodiments, the RNN is part of at least one of the PLMNs identified in the list. In some of these implementations, these example methods may also include determining whether the first cell is associated with any of the PLMN identifiers in the list. The indication can be based on the result of this determination, according to different variations discussed below. In some variants, the indication includes the following: • an identifier for the first cell, when the first cell is associated with at least one PLMN identifier included in the list; and • no identifier for the first cell, when the first cell is not associated with any of the PLMN identifiers included in the list. In other variants, the indication includes the following: • an identifier of the first cell, and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the user equipment reconnected to the wireless network for the first time after the link failure and the 1758931 of 73 failed connection restoration, on a PLMN that is not identified in the list. In other variants, the indication includes the following: • when the first cell is associated with at least one PLMN identifier included in the list, a first cell identifier, and an additional indication of the time elapsed between the link failure and the connection to the first cell; and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the UE reconnected to the wireless network for the first time, following the link failure and failed connection restoration, on a PLMN that is not identified in the list. In other variants, the indication includes the following: • an additional indication of the time elapsed between the link failure and the connection to the first cell; and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the user equipment reconnected to the wireless network for the first time, following the link failure and failed connection restoration, on a PLMN that is not identified in the list. Other embodiments include methods (e.g., procedures) for an RNN in a wireless network to receive failure reports from UEs. These example methods might include receiving, from a UE, a failure report that includes an indication of whether a first cell, to which the UE connected after a link failure and after a failed connection restoration on a first PLMN, is associated with the first PLMN. In some embodiments, the link failure is an RLF or a HOF declared by the UE on the first PLMN, and the failure report is an RLF report. In some embodiments, the failure report includes a list of PLMN identifiers associated with a cell where the link failure occurred, including an identifier of the first PLMN. In some of these embodiments, the RLN is part of at least one of the PLMNs identified in the list. In some embodiments, the link failure occurred in a second cell associated with the first PLMN, and the failed connection restoration occurred in a third cell associated with the first PLMN. In different variations, the indication can have any of the following forms and / or 1758931 of 73 previously summarized contents relating to the forms of EU implementation. In some embodiments, these example methods may also include selectively performing mobility parameter adjustments for the first cell based on an indication. For example, these operations may be part of the self-optimized network (SON) functionality, which is described in more detail below. In some embodiments, selective execution operations may include refraining from performing mobility parameter adjustments for the first cell when the indication shows that the first cell is not associated with the first PLMN where the UE connection failure was re-established. Other embodiments include UEs (e.g., wireless devices, IoT devices, etc., or components thereof) and RNNs (e.g., base stations, eNBs, gNBs, ng-eNBs, etc., or components thereof) configured to perform operations corresponding to any of the example methods described herein. Other embodiments include non-transient, computer-readable media that store program instructions which, when executed by processing circuits, configure such UEs or RNNs to perform operations corresponding to any of the example methods described herein. The implementation methods described herein facilitate the correct interpretation by a network of various contents of a UE's RLF report. For example, based on the RLF report content, the network node can identify whether the cell used for reconnection after a UE RLF and a failed reset belongs to a PLMN identified in the list included in the RLF report. Consequently, this allows the RNN to determine whether a mobility parameter adjustment procedure is required for this cell. In this way, the implementation methods facilitate better and more precise adjustment of the network's mobility parameters and, therefore, improved network performance. These and other objects, features and advantages of the forms of implementation of this disclosure will become evident upon reading the following detailed description in view of the drawings briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a high-level view of an example LTE network architecture. Figure 2 shows an example configuration of a protocol stack of the 1758931 of 73 LTE control plane (CP). Figure 3 shows a high-level view of an example 5G / NR network architecture. Figure 4 shows an example configuration of the NR user plane (UP) and CP protocol stacks. Figures 5-6 show high-level views of example network architectures that support multi-RAT dual connectivity (MR-DC) using EPC and 5GC, respectively. Figure 7 is a block diagram showing a high-level comparison of the control plane (CP) architectures for MR-DC using EPC and 5GC. Figures 8-9 illustrate various aspects of UE operation during a sample radio link failure (RLF) procedure in LTE and NR. Figures 10-11 show signal flow diagrams of two scenarios in which a UE declares RLF in an NR source cell and then unsuccessfully attempts a connection reset in an LTE destination cell. Figure 12, which includes Figures 12A-B, shows an example ASN.1 data structure for a UEInformationResponse message, according to various embodiments of this disclosure. Figure 13, which includes Figures 13A-B, shows an example ASN.1 data structure for another variant of a UEInformationResponse message, according to other embodiments of this disclosure. Figure 14 is a flowchart of an example method (e.g., procedure) for a UE (e.g., wireless device, IoT device, etc.), according to various embodiments of this disclosure. Figure 15 is a flowchart of an example method (e.g., procedure) for a radio network node (RNN, e.g., base station, eNB, gNB, ng-eNB, en-gNB, etc.), according to various embodiments of the present disclosure. Figure 16 illustrates one way to implement a wireless network. Figure 17 illustrates one embodiment of a UE. Figure 18 is a block diagram illustrating an example virtualization environment usable for implementing various forms of network node realization in a wireless network. Figures 19-20 are block diagrams of various communication systems and / or networks, according to various forms of implementation of this disclosure. 1758931 of 73 Figures 21-24 are example method flowcharts (e.g., procedures) for transmitting and / or receiving user data, according to various forms of implementation of this disclosure. DETAILED DESCRIPTION Some of the embodiments contemplated herein will now be described in more detail with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein; the disclosed subject matter should not be interpreted as being limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. In general, all terms used herein should be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or can be inferred from the context in which they are used. All references to one or more elements, apparatus, components, means, steps, etc., should be clearly interpreted as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or it is implied that one step must follow or precede another. Any feature of any of the embodiments set forth herein may be applied to any other embodiment, where appropriate.Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Other objectives, features, and advantages of the appended embodiments are derived from the following description. Furthermore, the following terms are used throughout the description that follows: • Radio node: As used herein, a “radio node” can be either a “radio access node” or a “wireless device.” • Radio access node: As used herein, a “radio access node” (or, equivalently, “radio network node,” “radio access network node,” or “RAN node”) can be any node in a radio access network (RAN) of a cellular communications network that functions to wirelessly transmit and / or receive signals. Examples of a radio access node include, 1758931 of 73 but without limitation, a base station (for example, a New Radio (NR) (gNB / en-gNB) base station in a 3GPP fifth generation (5G) NR network or an enhanced or evolved (eNB / ng-eNB) Node B in a 3GPP LTE network), distributed components of the base station (for example, CU and DU), control and / or user plane components of the base station (for example, CU-CP, CU-UP), a high-power or macro base station, a low-power base station (for example, micro, pico, femto, or home base station, or similar), an integrated access node (IAB), a transmit point, a remote radio unit (RRU or RRH), and a relay node. • Core network node: As used herein, a “core network node” is any type of node in a core network. Examples of a core network node include, for instance, a Mobility Management Entity (MME), a Service Gateway (SGW), a Packet Data Gateway (P-GW), an Access and Mobility Management Function (AMF), a Session Management Function (AMF), a User Plane Function (UPF), a Service Capacity Exposure Function (SCEF), or similar. • Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device that has access to (i.e., is served by) a cellular communications network by communicating wirelessly with network nodes and / or other wireless devices. Wireless communication may involve the transmission and / or reception of wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air.Some examples of a wireless device include, but are not limited to, smartphones, mobile phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, portable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), mobile-type communication (MTC) devices, Internet of Things (IoT) devices, and other devices. 1758931 of 73 vehicle-mounted wireless terminals, etc. Unless otherwise stated, the term “wireless device” is used interchangeably in this document with the term “user equipment” (or “UE” for short). • Network node: As used herein, a “network node” is any node that is part of the radio access network (e.g., a radio access node or equivalent name discussed previously) or the core network (e.g., a core network node discussed previously) of a cellular communications network. Functionally, a network node is equipment capable, configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or other network nodes or equipment in the cellular communications network, to enable and / or provide wireless access to the wireless device, and / or to perform other functions (e.g., management) in the cellular communications network. Note that the description in this document focuses on a 3GPP cellular communications system and, as such, often uses 3GPP or 3GPP-like terminology. However, the concepts discussed here are not limited to a 3GPP system. Furthermore, although the term “cell” is used here, it should be understood that (particularly with regard to 5G NR) beams can be used instead of cells, and as such, the concepts described here apply equally to both cells and beams. As briefly mentioned, conventional RLF notification techniques present several problems, issues, and / or difficulties when a UE finally connects to an LTE cell after declaring an RLF in an NR cell. This is discussed in more detail below, following the description of the NR network architecture and the various dual connectivity (DC) arrangements. Figure 3 illustrates a high-level view of the 5G network architecture, which consists of a next-generation RAN (NG-RAN) 399 and a 5G core (5GC) 398. The NG-RAN 399 can include a set of gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 300 and 350 connected via interfaces 302 and 352, respectively. Furthermore, the gNBs can be interconnected via one or more Xn interfaces, such as the Xn interface 340 between gNBs 300 and 350. Regarding the NR interface for the UEs, each gNB can support frequency-division duplex (FDD), time-division duplex (TDD), or a combination of these. 1758931 of 73 The NG-RAN 399 is divided into a radio network layer (RNL) and a transport network layer (TNL). The logical nodes of the NG-RAN and the interfaces between them are part of the RNL. The TNL provides services for user plane (UP) transport and signaling transport, with the TNL protocols and related functionality specified for each NG-RAN interface (e.g., NG, Xn, F1). In some example configurations, each gNB is connected to all 5GC nodes within an “AMF region,” and the term AMF is discussed in more detail below. The logical nodes of the NG-RAN shown in Figure 3 include a central (or centralized) unit (CU or gNB-CU) and one or more distributed (or decentralized) units (DU or gNB-DU). For example, gNB 300 includes gNB-CU 310 and gNB-DUs 320 and 330. The CUs (e.g., gNB-CU 310) are logical nodes that host upper-layer protocols and perform various gNB functions, such as controlling the operation of the DUs. Each DU is a logical node that hosts lower-layer protocols and may include, depending on the functional division, several subsets of gNB functions. As such, each CU and DU may include various circuits necessary to perform its respective functions, including processing circuits, transceiver circuits (e.g., for communication), and power circuits.Furthermore, the terms “central unit” and “centralized unit” are used interchangeably in this document, as are the terms “distributed unit” and “decentralized unit”. A gNB-CU connects to the gNB-DUs via their respective F1 logical interfaces, such as interfaces 322 and 332 shown in Figure 3. The connected gNB-CU and gNB-DUs are only visible to other gNBs and the 5GC as gNBs. In other words, the F1 interface is not visible beyond the gNB-CU. In the split gNB CU-DU architecture illustrated in Figure 3, DC can be achieved by allowing a UE to connect to multiple DUs served by the same CU or by allowing a UE to connect to multiple DUs served by different CUs. Figure 4 shows an example configuration of the NR UP and control plane (CP) protocol stacks between a UE, a gNB, and an access and mobility management function (AMF) on the 5GC. The PHY, MAC, RLC, and PDCP layers between the UE and the gNB are common to both UP and CP. The PDCP layer provides encryption / decryption, integrity protection, sequence numbering, reordering, and duplicate detection for both CP and UP. Additionally, PDCP provides header compression and retransmission for UP data. 1758931 of 73 On the upstream side, Internet Protocol (IP) packets arrive at the PDCP layer as Service Data Units (SDUs), and PDCP creates Protocol Data Units (PDUs) for delivery to the RLC. When each IP packet arrives, PDCP starts a discard timer. When this timer expires, PDCP discards the associated SDU and the corresponding PDU. If the PDU was delivered to the RLC, PDCP also signals the discard to the RLC. The RLC layer transfers the PDUs from PDCP to the MAC layer via Logical Channels (LCHs). The RLC provides error detection / correction, concatenation, segmentation / reassembly, sequence numbering, and reordering of data transferred to / from the upper layers. If the RLC receives a discard signal associated with a PDCP PDU, it will discard the corresponding RLC SDU (or any segment of it) if it has not been sent to the lower layers. The MAC layer provides mapping between LCHs and PHY transport channels, LCH prioritization, multiplexing into or demultiplexing from transport blocks (TBs), hybrid ARQ error correction (HARQ), and dynamic scheduling (on the gNB side). The PHY layer provides transport channel services to the MAC layer and manages the transfer across the NR radio interface, for example, through modulation, coding, antenna mapping, and beamforming. On the UP side, the Service Data Adaptation Protocol (SDAP) layer manages quality of service (QoS). This includes mapping QoS flows to data radio carriers (DRBs) and marking QoS flow identifiers (QFIs) in UL and DL packets. On the CP side, the NAS layer sits between the UE and the AMF and manages UE / gNB authentication, mobility management, and security control. The RRC layer is located below the NAS in the UE, but terminates in the gNB instead of the AMF. The RRC controls communications between the UE and the gNB at the radio interface, as well as UE mobility between cells in the NG-RAN. The RRC also disseminates system information (SI) and performs the establishment, configuration, maintenance, and release of the DRBs and signaling radio carriers (SRBs) used by the UEs. Furthermore, the RRC controls the addition, modification, and release of carrier aggregation (CA) and dual connectivity (DC) configurations for the UEs. The RRC also performs various security functions, such as key management. After powering on a UE, it will be in the RRC_IDLE state until an RRC connection is established with the network, at which point the device will transition to the RRC_IDLE state. 1758931 of 73 RRC_CONNECTED (for example, where data transfer can occur). The equipment returns to the RRC_IDLE state when the network connection is released. In the RRC_IDLE state, the UE's radio is active on a discontinuous receive (DRX) schedule configured by the upper layers. During active DRX periods (also called "DRX On durations"), a UE in RRC_IDLE receives the SI broadcast in the cell where the UE is camping, performs measurements of neighboring cells to support cell reselection, and monitors a paging channel on PDCCH for 5GC pages via gNB. An NR UE in the RRC_IDLE state is not known to the gNB serving the cell where the UE is camping. However, NR RRC includes an RRC_INACTIVE state where a UE is known (for example, through the UE's context) by the server gNB. RRC_INACTIVE has some properties similar to the "suspended" state used in LTE. LTE Rel-12 introduced dual connectivity (DC), whereby a UE in the RRC_CONNECTED state can connect to two network nodes simultaneously, improving connection robustness and / or capacity. In LTE DC, these two network nodes are called the "master eNB" (MeNB) and "secondary eNB" (SeNB), or more generally, the master node (MN) and secondary node (SN). More specifically, a UE is configured with a Master Cell Group (MCG) associated with the MN and a Secondary Cell Group (SCG) associated with the SN. Each of these server cell groups includes a MAC entity, a set of logical channels with associated RLC entities, a primary cell (PCell or PSCell), and optionally one or more secondary cells (SCells). The term “special cell” (or “SpCell” for short) refers to the PCell of the MCG or the PSCell of the SCG, depending on whether the UE's MAC entity is associated with the MCG or the SCG, respectively. In non-DC operation (e.g., CA), SpCell refers to the PCell. A SpCell is always active and supports transmission of the physical uplink control channel (PUCCH) and contention-based random access by the UEs. The MN provides SIs and terminates the CP connection to the UE and, as such, is the UE's control node, including for handovers to and from SNs. For example, the MN terminates the connection between the RAN (e.g., the eNB) and the MME for an LTE UE. Reconfiguration, addition, and deletion of SCells can be performed by the RRC. When a new SCell is added, dedicated RRC signaling is used to send the UE all the required SIs from the SCell, so UEs do not need to acquire them. 1758931 of 73 the SI directly from the SCell diffusion. In addition, the MCG and the SCG, or both, may include multiple cells that operate on AC. Both the MN and the SN can terminate the UP to the UE. For example, the LTE DC UP includes three different types of carriers. MCG carriers are terminated at the MN, and the SN does not participate in UP data transport for MCG carriers. Similarly, SCG carriers are terminated at the SN, and the MN does not participate in UP data transport for SCG carriers. Finally, split carriers (and their corresponding S1-U connections to the S-GW) are also terminated at the MN. However, PDCP data is transferred between the MN and the SN via X2-U. Both the SN and the MN participate in data transmission for split carriers. 3GPP TR 38.804 (v14.0.0) describes several example DC scenarios or configurations in which the MN and SN can implement NR, LTE, or both. The following terminology is used to describe these example DC scenarios or configurations: • DC: LTE DC (i.e., both the MN and SN use LTE, as discussed previously); • EN-DC: LTE-NR DC where the MN (eNB) uses LTE and the SN (gNB) uses NR, and both are connected to the EPC. • NGEN-DC: Dual LTE-NR connectivity where a UE is connected to an ng-eNB acting as the MN and a gNB acting as the SN. The ng-eNB is connected to the 5GC and the gNB is connected to the ng-eNB via the Xn interface. • NE-DC: Dual LTE-NR connectivity where a UE is connected to a gNB acting as the MN and an ng-eNB acting as the SN. The gNB is connected to the 5GC and the ng-eNB is connected to the gNB via the Xn interface. • NR-DC (or NR-NR DC): both the MN and the SN use NR. • MR-DC (multi-RAT DC): a generalization of Intra-E-Dual Connectivity UTRA (DC), described in 3GPP TS 36.300 (v16.3.0), allows a multiple Rx / Tx UE to be configured to utilize resources provided by two different nodes connected via a non-ideal backhaul. One node provides E-UTRA access, and the other provides NR access. One node acts as the MN, and the other as the SN. The MN and SN are connected through a network interface, and at least the MN is connected to the core network. EN-DC, NE-DC, and NGEN-DC are different example cases of MR-DC. 1758931 of 73 Figure 5 shows a high-level view of a sample network architecture supporting EN-DC, including an E-UTRAN 599 and an EPC 598. As shown in the figure, the E-UTRAN 599 can include en-gNBs (e.g., 510a,b) and eNBs (e.g., 520a,b) that are interconnected via their respective X2 (or X2-U) interfaces. The eNBs can be similar to those shown in Figure 1, while the ng-eNBs can be similar to the gNBs shown in Figure 3, except that they connect to the EPC 598 via an S1-U interface instead of to a 5GC via an X2 interface. The eNBs also connect to the EPC 598 via an S1 interface, similar to the arrangement shown in Figure 1. More specifically, the en-gNBs (e.g., 510a,b) and the eNBs (e.g., 520a,b) connect to the MMEs (e.g., 530a,b) and the S-GWs (e.g., 540a,b) on the EPC 598. Each en-gNB and eNB can serve a geographic coverage area that includes one additional cell, including example cells 511a and 521ab shown in Figure 5. Depending on the cell it is in, a UE 505 can communicate with the en-gNB or eNB serving that cell via the NR or LTE radio interface, respectively. Furthermore, the UE 505 can be in EN-DC connectivity with a first cell served by an eNB and a second cell served by an en-gNB, such as cells 520a and 510a shown in Figure 5. Figure 6 shows a high-level view of a sample network architecture supporting MR-DC configurations based on a 5GC. More specifically, Figure 6 shows an NG-RAN 699 and a 5GC 698. The NG-RAN 699 may include gNBs (e.g., 610a,b) and ng-eNBs (e.g., 620a,b) interconnected via their respective Xn interfaces. The gNBs and ng-eNBs are also connected via NG interfaces to the 5GC 698, specifically to the AMFs (e.g., 630a,b) via their respective NG-C interfaces and to the User Plane Functions (UPFs, e.g., 640a,b) via their respective NGU interfaces. In addition, AMFs can communicate with one or more session management functions (SMF, for example, 650a,b) and network exposure functions (NEF, for example, 660a,b). Each gNB can be similar to those shown in Figure 3, while each ng-eNB can be similar to the eNBs shown in Figure 1, except that they connect to 5GC 698 via an NG interface instead of to an EPC via an S1 interface. Each gNB and ng-eNB can serve a geographic coverage area that includes one more cell, including the example cells. 1758931 of 73 Cells 611a and 621a-b are shown in Figure 6. The gNB and ng-eNB can also use multiple directional beams to provide coverage in their respective cells. Depending on the cell it is in, a UE 605 can communicate with the gNB or ng-eNB serving that cell via the NR or LTE radio interface, respectively. Additionally, the UE 605 can be in MR-DC connectivity with a first cell served by an ng-eNB and a second cell served by a gNB, such as cells 620a and 610a shown in Figure 6. One of the main objectives of Self-Organizing Network (SON) functionality is to simplify and expedite the planning, configuration, management, optimization, and repair of RANs. SON functionality and behavior have been defined and specified by organizations such as 3GPP and NGMN (Next Generation Mobile Networks). Figure 7 is a high-level diagram illustrating how 3GPP has divided SON functionality into a self-configuration process and a self-optimization process. Autoconfiguration is a pre-operational process where newly deployed nodes (e.g., eNBs or gNBs in a pre-operational state) are configured using automated installation procedures to obtain the basic configuration necessary for system operation. The pre-operational state generally refers to the period from when the node is powered on and has backbone connectivity until the node's RF transmitter is powered on. Autoconfiguration operations in the pre-operational state include (A) basic configuration and (B) initial radio configuration, which include the following sub-operations shown in Figure 7: • (a-1) IP address configuration and detection of operations management and maintenance (OAM); • (a-2) eNB / network authentication; • (a-3) Association to the access gateway (aGW); • (a-4) Downloading the eNB software (SW) and operating parameters; • (b-1) Neighbor list configuration; and • (b-2) Configuration of parameters related to coverage / capacity. Self-optimization is a process where measurements from user equipment and the network are used to self-adjust the network. This occurs when nodes are in an operational state, which generally refers to when a node's RF transmitter interface is powered on. Self-configuration operations include optimization and adaptation, which encompass the following sub-operations: 1758931 of 73 shown in Figure 7: • (c-1) Neighbor list optimization; and • (c-2) Coverage / capacity control. The self-configuration and self-optimization features for LTE networks are described in section 22.2 of 3GPP TS 36.300 (v16.5.0). These include dynamic configuration, automatic neighbor relationships (ANR), mobility load balancing (MLB), mobility robustness optimization (MRO), rack rate optimization (RACH), and power saving support. The self-configuration and self-optimization features for NR networks are described in section 15 of 3GPP TS 38.300 (v16.5.0). Features in Rel-15 include dynamic configuration and ANR. Rel-16 includes additional features such as MRO. Returning to the RLF discussion, a network can configure a UE in the RRC_CONNECTED state to perform and report RRM measurements that aid network-controlled mobility decisions, such as UE handovers between cells, SN changes, etc. The UE might lose coverage in its current service cell (e.g., PCell at DC) and attempt a handover to a destination cell. Similarly, a UE at DC might lose coverage in its current PSCell and attempt an SN change. Other events can trigger additional mobility-related procedures. A UE typically triggers an internal RLF procedure when something unexpected occurs in any of these mobility-related procedures. The RLF procedure involves interactions between the RRC and lower-layer protocols, such as PHY (or L1), MAC, RLC, etc., including Radio Link Monitoring (RLM) at L1. The principle of RLM is similar in LTE and NR. In general, the user equipment monitors the link quality of the user equipment's service cell (i.e., SpCell) and uses that information to decide whether the user equipment is in sync (IS) or out of sync (OOS) with respect to that service cell. In LTE, RLM involves the UE measuring downlink reference signals (e.g., CRS) in the RRC_CONNECTED state. If RLM (i.e., via L1 / PHY) indicates a number of consecutive OOS conditions to the UE's RRC layer, then the RRC initiates a radio link failure (RLF) procedure and declares RLF after the expiration of a timer (e.g., T310). The L1 RLM procedure is carried out by comparing the estimated CRS measurements with some Qout and Qin targets, which correspond to the block error rates (BLERs) of hypothetical transmissions. 1758931 of 73 PDCCH / PCIFCH of the server cell. Example values ​​for Qout and Qin are 10% and 2%, respectively. In NR, the network can define the RS type (e.g., CSI-RS and / or SSB), the exact resources to be monitored, and the BLER target for IS and OOS indications. Figure 8 shows a high-level time diagram illustrating the two phases of an RLF procedure in LTE and NR. The first phase begins with the detection of a radio problem and leads to the detection of a radio link failure if there is no recovery during a period T1. The second phase begins with the detection of a radio problem or a handover failure and ends with the equipment returning to RRC_IDLE if it does not recover during the period T2. Figure 9 shows a more detailed version of the UE operations during a sample RLF procedure, such as for LTE or NR. In this example, the UE detects consecutive OOS conditions (N310) during the L1 RLM procedures, as discussed earlier, and then starts timer T310. Subsequent operations are performed by the upper layers (e.g., RRC). After T310 expires, the UE declares RLF and initiates T311 and the RRC reset, searching for the best target cell. After selecting a target cell, the user equipment obtains system information (SI) for the target cell and performs random access (e.g., via RACH). The duration after T310 expires up to this point can be considered the UE reset delay. Finally, the user equipment gains access to the target cell and sends an RRC reset request message to the target cell.The duration after the expiration of T310 up to this point can be considered the total RRC reset delay. If the user equipment does not successfully reset to a target cell before the expiration of T311, the user equipment enters RRC_IDLE and releases its connection to the network. Tables 1-2 below provide further details on the timers and counters described above. For NR-DC and NGEN-DC, T310 is used for both PCell / MCG and PSCell / SCG. For LTE-DC and NE-DC (i.e., when the SN is eNB), T313 is used for PSCell / SCG. The UE reads the timer values ​​from the System Information (SI) broadcast on the UE's SpCell. Alternatively, the network can configure the UE with specific timer and constant values ​​via dedicated RRC signaling (i.e., specific values ​​sent to specific UEs via their respective messages). 1758931 of 73 Table 1. Timer Start Stop At expiration T310 Upon detecting problems in the physical layer of the SpCell, i.e., upon receiving consecutive N310 desynchronization indications from the lower layers. Upon receiving consecutive N311 synchronization indications from the lower layers for the SpCell, upon receiving RRCReconfiguration with reconfiguration WithSync for that cell group, and upon initiating the connection restoration procedure. Upon releasing the SCG, if T310 remains in the SCG. If T310 remains in MCG: If AS security is not activated: switch to RRCIDLE; otherwise: initiate the connection restoration procedure. If T310 remains in SCG, inform EUTRAN / NR about the SCG radio link failure by initiating the SCG failure reporting procedure as specified in 5.7.3. T311 When starting the RRC connection reset procedure When selecting a suitable NR cell or a cell that uses another RAT.Enter RRC_IDLE T313 Upon detecting problems in the PSCell physical layer, i.e., upon receiving N313 consecutive desynchronization indications from the lower layers Upon receiving N314 consecutive synchronization indications from the lower layers for the PSCell, upon initiating the connection restoration procedure, upon releasing the SCG and upon receiving RRCConnectionReconfiguration including MobilityControlInfoSCG Inform the E-UTRAN about the SCG radio link failure by initiating the SCG failure information procedure as specified in 5.6.13. Table 2. Constant Use N310 Maximum number of consecutive “out-of-sync” indications for the SpCell received from lower layers N311 Maximum number of consecutive “in-sync” indications for the SpCell received from lower layers N313 Maximum number of consecutive “out-of-sync” indications for the PSCell received from lower layers (for LTE SN) One of the reasons for introducing the timers and counters listed above is to add some kind of filter, delay and / or hysteresis to the determination 20 1758931 of 73 by a UE regarding a radio link failure and / or recovery with a service cell. These parameters prevent a UE from prematurely abandoning a connection due to a brief or temporary reduction in link quality that could be recovered by the UE (e.g., before T310 expires, before the N310 counter value, etc.). Overall, this improves the user experience. In the event of a Handover Failure (HOF) and Reliable Link Failure (RLF), the UE can take autonomous actions such as selecting a cell and initiating a reconnection process to remain reachable by the network. Generally, a UE declares an RLF only when it realizes that a reliable communication channel (or radio link) is unavailable between it and the network, which can lead to a poor user experience. Furthermore, reconnecting requires signaling with a newly selected cell (e.g., the random access procedure, the exchange of multiple RRC messages, etc.), which introduces latency until the UE can reliably transmit and / or receive user data with the network again. According to 3GPP TS 36.331 (v15.7.0), potential causes of RLF include the following: 1) Radio link problem indicated by PHY (e.g., T310 timer expiration related to RLM); 2) Random access problem indicated by the MAC entity; 3) Expiration of a measurement report timer (for example, T312), because no HO command is received from the network while the timer is running despite having sent a measurement report; and 4) Achieve a maximum number of RLC retransmissions. Since RLFs lead to resetting to a new cell and degradation of UE / network performance and end-user experience, it is in the network's interest to understand the reasons for the UE's RLFs and optimize mobility-related parameters (e.g., measurement report activation conditions) to reduce, minimize, and / or prevent subsequent RLFs. Before the Rel-9 Mobility Robustness Optimizations (MROs), only the UE knew the radio quality at the time of the RLF, the actual reason for declaring the RLF, etc. To identify the cause of the RLF, the network requires more information from the UE and neighboring base stations (e.g., eNBs). An RLF notification procedure was introduced as part of MRO for NR Rel-16. In this procedure, a user team records the relevant information at the time of the RLF and subsequently reports that information to the 1758931 of 73 network through a destination cell to which the user equipment ultimately connects (for example, after a reset). The UE can store the RLF report in a UE variable called VarRLF-Report and retain it in memory for up to 48 hours, after which it can discard the information. When certain RRC messages are sent, such as RRCReconfigurationComplete, RRCReestablishmentComplete, RRCSetup-Complete, and RRCResumeComplete, the UE can indicate that it has a stored RLF report by setting the rlf-InfoAvailable field to “true”. If the gNB servicing the target cell wants to receive the RLF report, it sends the UE an UEInformationRequest message with the flag “rlf-ReportReq-r16”. In response, the UE sends the gNB a UEInformationResponse message containing the RLF report. In general, the RLF information communicated by the EU may include any of the following elements: • Measurement quantities (RSRP, RSRQ) of the last server cell (PCell). • Measurement quantities of neighboring cells at different frequencies of different RATs (e.g., EUTRA, UTRA, GERAN, CDMA2000). • Measurement amount (RSSI) associated with WLAN APs. • Number of measurements (RSSI) associated with Bluetooth beacons. • Location information, if available (including location coordinates and speed) • Globally unique identity of the last server cell, if available; otherwise, the PCI and carrier frequency of the last server cell. • PCell tracking area code. • Time elapsed since the last receipt of the “Handover command” message. • C-RNTI used in the previous server cell. • If the UE was configured with a DRB with QCI = 1. The RLF reporting procedure not only introduced new RRC signaling between the UE and the network (for example, a destination gNB hosting the destination cell), but also introduced signaling between network nodes (for example, the XnAP signaling specified in 3GPP TS 38.423 v16.4.0). For example, a gNB receiving an RLF report could forward part or all of the report to the gNB where the RLF originated. 3GPP TS 38.423 specifies two types of inter-node messages for 1758931 of 73 RLF report sending between nodes: Failure indication and Handover report. Based on the globally unique identity of the last user equipment service cell included in the RLF report, the node serving the target cell (i.e., the new user equipment service cell) can determine the cell where the RLF originated and send the RLF report to the source gNB serving that cell. Based on this RLF report, the source gNB can deduce whether the UE RLF in that cell was caused by a coverage hole or by parameter settings related to handover. In the case of the latter, the source gNB can further classify the handover-related failure as too early, too late, or handover to the wrong cell. The originating gNB may classify a handover failure as "too late a handover" when the original service cell does not send the handover command to the user equipment associated with a handover to a specific destination cell, and if the user equipment resets to this destination cell after the RLF (Return Failed). An example of corrective action by the originating gNB could be to initiate the handover procedure from the originating cell to this destination cell slightly earlier, decreasing the individual cell (CIO) travel to the destination cell. The CIO controls when the IE (Intermediate Entity) sends the measurement report triggered by the event that leads to the handover decision. The originating gNB may classify a handover failure as "too premature" when the original service cell successfully sends the handover command to the user computer, but the user computer fails to establish random access to the destination cell. An example of corrective action by the originating gNB could be to initiate the handover procedure from the source cell to the destination cell slightly later, increasing the CIO (Cycle-Integrated Operations) to the destination cell. The originating gNB may classify a handover failure as "handover to the wrong cell" when the original service cell attempts to perform the handover for this UE to a specific destination cell, but the UE declares an RLF and resets to a different destination cell. A corrective action by the originating gNB could be to initiate the measurement reporting procedure leading to the handover from the originating cell to the destination cell slightly later, decreasing the CIO, or to initiate the handover to the different destination cell where the UE reset slightly earlier, increasing the CIO to the different destination cell. For Rel-16, a reconnectCellID parameter was added to the RLF report in both the LTE and NR specifications. This information is supposed to identify a cell. 1758931 of 73 LTE in which the UE re-established its connection after declaring an RLF in an NR cell. This scenario was expected to occur frequently during initial NR deployments, where UEs were expected to remain in NR cells for as long as possible, thus risking delayed handovers between RATs and LTE. By identifying the destination LTE cell where the RLF occurred, the source NR cell can improve the inter-RAT handover parameters to this LTE cell, thereby reducing the likelihood of future RLFs. As currently specified, the user equipment records the reconnectCellID if the reconnection occurs on the same PLMN as the RLF or on a PLMN that is part of the user equipment's stored plmn-IdentityList. The purpose of the reconnectCellID is to capture the first cell to which the UE reconnects after the RLF / HOF has been declared by the UE and subsequently failed to reconnect. Figure 10 shows a signal flow diagram of a scenario where a UE declares an RLF (operation 2) from an RRC connection (established in operation 1) on an NR cell served by gNB1 on PLMN1. In operations 3-4, the UE attempts a failed reconnection to a target cell and subsequently reconnects to a target cell served by eNB1 on PLMN1, which is the same PLMN where the failed reconnection occurred.In operations 5-6, the UE sends an RLF report to eNB1 and includes the reconnectCellID for the target cell served by eNB1 in the RLF report. In operation 7, eNB1 sends the RLF report to gNB1 on PLMN1, to which the... The following 3GPP procedural text also illustrates the operations of EU in Figure 10: *** 3GPP procedure text begins *** 1> If the UE has radio link failure or handover failure information available in VarRLF-Report and if the RPLMN is included in plmn-IdentityList stored in VarRLFReport: 2> If reconnectCellID in VarRLF-Report is not set: 3> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover; 3> set nrReconnectCellId in reconnectCellID in VarRLF-Report to the global cell identity and PCell trace area code; 1> if the UE supports the RLF report for MRO NR inter-RAT as defined in TS 36.306

[62] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 36.331

[10] and if the RPLMN is included in plmn- 1758931 of 73 IdentityList stored in VarRLF-Report of TS 36.331

[10] : 2> If reconnectCellID in VarRLF-Report of TS 36.331

[10] is not set: 3> set timeUntilReconnection in VarRLF-Report of TS 36.331

[10] to the time elapsed since the last radio link failure or handover failure in LTE; 3> set nrReconnectCellId in reconnectCellID in VarRLF-Report of TS 36.331

[10] to the global cell identity and PCell trace area code; *** End of 3GPP procedure text *** Figure 11 shows a signal flow diagram of another example scenario where a UE declares an RLF (operation 2) from an RRC connection (established in operation 1) to an NR cell served by gNB1 of PLMN1. In this scenario, the UE fails to re-establish the connection to gNB1 (operation 3), but then re-establishes a connection (operation 4) to a destination cell served by eNB1 of PLMN2, i.e., a different PLMN. In this scenario, the UE does not include the reconnectCellID for the destination cell served by eNB1 in the RLF report sent to eNB1, since PLMN2 is different from the PLMN1 where the RLF occurred. Furthermore, PLMN2 is not part of the UE's stored plmn-IdentityList. In operations 5–7, the user equipment subsequently reconnects to a destination cell served by eNB2 of PLMN1. In operations 8-9, the UE includes reconnectCellID for the destination cell in the RLF report sent to eNB2, in accordance with the procedure text above. In summary, when the cell to which the user computer first reconnects after the RLF and failed reset belongs to a PLMN that is not part of the user computer's plmn-IdentityList, the user computer does not include that cell as the reconnectCellID in the RLF report. Instead, the reconnectCellID included by the UE in such scenarios is the cell in the UE's plmn-IdentityList to which the UE first reconnects (i.e., transmits an RRCSetup or RRCConnectionSetup message) after the RLF and failed reset. However, this behavior does not fulfill the purpose of having the reconnectCellID in the RLF report, which is to capture the first cell to which the UE reconnects after the RLF and failed reset. Therefore, a network node receiving an RLF report may misinterpret this information, causing it to unnecessarily adjust the parameters (e.g., CIO) of the cells it services. Accordingly, the methods used to implement this disclosure provide techniques that ensure that the reconnectCellID information included in the The RLF report 1758931 of 73 can be correctly interpreted by a receiving network node. Based on the content of the RLF report, the network node can identify whether the cell used for reconnection after the RLF / HOF and failed reset belongs to the same PLMN as the plmn-IdentityList stored in the RLF report. Consequently, the network node can determine whether a mobility parameter adjustment procedure should be used for the reconnectCellID included in the RLF report. For example, if the reconnectCellID included in the RLF report is not the first cell after the failed reset, then the network node can refrain from performing any mobility parameter adjustments on the cell identified by the reconnectCellID. These implementations facilitate better adjustment of network mobility parameters. In some implementations, a UE does not include the reconnectCellID in the RLF report if the cell to which the UE first reconnected after the RLF and the subsequent failed reset belongs to a PLMN that is not listed in the plmn-IdentityList stored in the RLF report. In some cases, however, this approach can be suboptimal, as the reconnectCellID included in the RLF report serves as an indirect identifier that the reset failed. If the user equipment does not include the reconnectCellID in cases where the first cell to which the user equipment reconnected after the RLF and the subsequent failed reset belongs to a PLMN that is not listed in the plmn-IdentityList stored in the RLF report, the network cannot deduce, based on the RLF report, whether the reset was successful or not. These implementation methods are also illustrated by the following procedural text, which may form part of an NR RRC standard such as 3GPP TS 38.331 (v16.4.1). Note that this text may omit certain operations performed by the EU for the sake of brevity, and may be combined with the existing text in 3GPP TS 38.331 (v16.4.1). *** 3GPP procedure text begins *** The UE must perform the following actions after receiving the RRCSetup: 1> If the UE has radio link failure or handover failure information available in VarRLF-Report and if the RPLMN is included in plmn-IdentityList stored in VarRLFReport: 2> If reconnectCellID in VarRLF-Report is not set and if this is the first RRCSetup received by the UE after declaring RLF / HOF: 1758931 of 73 3> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover failure; 3> set nrReconnectCellID in reconnectCellID in VarRLF-Report to the global cell identity and PCell trace area code; 1> If the UE supports the RLF report for MRO NR inter-RAT as defined in TS 36.306

[62] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 36.331

[10] and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report of TS 36.331

[10] : 2> If reconnectCellID in VarRLF-Report of TS 36.331

[10] is not set and if this is the first RRCSetup received by the UE after declaring RLF / HOF: 3> set timeUntilReconnection in VarRLF-Report of TS 36.331

[10] to the time elapsed since the last radio link failure or handover failure in LTE; 3> set nrReconnectCellID in reconnectCellID in VarRLF-Report of TS 36.331

[10] to the global cell identity and PCell trace area code; 1> Send the RRCSetupComplete message to the lower layers for transmission, after which the procedure ends. *** End of 3GPP procedure text *** These implementations are also illustrated by the following procedural text, which may form part of an LTE RRC standard such as 3GPP TS 36.331 (v16.4.0). Note that this text may omit certain operations performed by the UE for the sake of brevity, and may be combined with the existing text in 3GPP TS 36.331 (v16.4.0). *** 3GPP procedure text begins *** The UE must [after receiving RRCConnectionSetup]: 1> except for NB-IoT: 2> if the UE supports the RLF report for EUTRA MRO inter-RAT as defined in TS 38.306

[87] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 38.331

[82] and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report of TS 38.331

[82] : 3> if reconnect Cellid in VarRLF-Report of TS 38.331

[82] is not set 1758931 of 73 and if this is the first RRCSetup received by the UE after declaring RLF / HOF: 4> set timeUntilReconnection in VarRLF-Report of TS 38.331

[82] to the time elapsed since the last radio link failure or handover; 4> set eutraReconnectCellID in reconnectCellID in VarRLF-Report of TS 38.331

[82] to the global cell identity and PCell trace area code; 1> Set the content of the RRCConnectionSetupComplete message as follows: 2> If the UE is connected to the EPC: 3> except for NB-IoT: 4> If the UE has radio link failure or handover failure information available in VarRLF-Report and if the RPLMN is included in plmnIdentityList stored in VarRLF-Report: 5> If reconnectCellID in VarRLF-Report is not and if this is the first RRCSetup received by the UE after declaring RLF / HOF: 6> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover failure; 6> set eutraReconnectCellID in reconnectCellID in VarRLFReport to the global cell identity and PCell tracking area code; 5> include rlf-InfoAvailable; 1> sends the RRCConnectionSetupComplete message to the lower layers for transmission; 1> The procedure ends. *** 3GPP procedure text begins *** In other implementations, a UE can include an indicator in the RLF report when the reconnectCellID (included in the RLF report) is not the first cell to which the UE reconnected after the RLF and subsequent failed reset. These implementations have the advantage that the network node can determine, based on the contents of the RLF report, whether the reset was successful and whether the reconnectCellID in the RLF report was the first cell to which the UE reconnected (for example, whether the first reconnection occurred in a cell belonging to a different PLMN). 1758931 of 73 These implementation methods can be illustrated by the following procedural text, which may form part of an NR RRC standard such as 3GPP TS 38.331 (v16.4.1). Note that this text may omit certain operations performed by the EU for the sake of brevity, and may be combined with the existing text in 3GPP TS 38.331 (v16.4.1). *** 3GPP procedure text begins *** The UE must perform the following actions after receiving the RRCSetup: 1> If the UE has radio link failure or handover failure information available in VarRLF-Report: 2> If this is the first RRCSetup received by the UE after declaring RLF / HOF and if the RPLMN is not included in plmn-IdentityList stored in VarRLFReport: 3> sets firstReconnectionInDifferentPLMN in VarRLF-Report to valid; 2> if reconnectCellID in VarRLF-Report is not set 3> If the RPLMN is included in plmn-IdentityList stored in VarRLFReport: 4> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover; 4> set nrReconnectCellID in reconnectCellID in VarRLF-Report to the global cell identity and PCell tracking area code; 1> if the UE supports the RLF report for MRO NR inter-RAT as defined in TS 36.306

[62] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 36.331

[10] : 2> if this is the first RRCSetup received by the UE after declaring RLF / HOF and if the RPLMN is not included in plmn-IdentityList stored in VarRLF-Report of TS 36.331

[10] : 3> set firstReconnectionInDifferentPLMN in VarRLF-Report of TS 36.331 [10 to valid; 2> if reconnectCellID in VarRLF-Report of TS 36.331

[10] is not set 3> if the RPLMN is included in plmn-IdentityList stored in VarRLFReport of TS 36.331

[10] : 4> set timeUntilReconnection in VarRLF-Report of TS 36.331

[10] to the time elapsed since the last radio link failure or handover failure in LTE; 1758931 of 73 4> set nrReconnectCellID in reconnectCellID in VarRLF-Report of TS 36.331

[10] to the global cell identity and PCell trace area code; 1>present the RRCSetup Complete message to the lower layers for transmission, after which the procedure ends. *** End of 3GPP procedure text *** Figure 12, which includes Figures 12A-B, shows an ASN.1 data structure for a sample UEInformationResponse message that includes an information element (IE) RLF-Report-r16 in accordance with the preceding sample procedure text for NR RRC. This IE includes an optional field firstReconnectionInDifferentPLMN-r16xy which, if present, indicates that the first cell in which the UE performed the RRC connection establishment after declaring RLF / HOF and not performing the reset belongs to a PLMN different from the plmnIdentityList stored in VarRLF-Report. These embodiments can also be illustrated by the following procedural text, which may form part of an LTE RRC standard such as 3GPP TS 36.331 (v16.4.0). Note that this text may omit certain operations performed by the UE for the sake of brevity, and may be combined with the existing text in 3GPP TS 36.331 (v16.4.0). *** 3GPP procedure text begins *** The UE must [after receiving RRCConnectionSetup]: 1> except for NB-IoT: 2> if the UE supports the RLF report for EUTRA MRO inter-RAT as defined in TS 38.306

[87] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 38.331

[82] : 3> if this is the first RRCSetup received by the UE after declaring RLF / HOF and if the RPLMN is not included in plmn-IdentityList stored in VarRLF-Report of TS 38.331

[82] : 4> set firstReconnectionInDifferentPLMN in VarRLF-Report of TS 38.331

[82] to true; 3> if reconnectCellID in VarRLF-Report of TS 38.331

[82] is not set 4> if the RPLMN is included in plmn-IdentityList stored in VarRLFReport of TS 38.331

[82] 1758931 of 73 5> set timeUntilReconnection in VarRLF-Report of TS 38.331

[82] to the time elapsed since the last radio link failure or handover failure; 5> set eutraReconnectCellID in reconnectCellID in VarRLFReport of TS 38.331

[82] to the global cell identity and PCell trace area code; 1> Set the content of the RRCConnectionSetupComplete message as follows: 2> If the UE is connected to EPC: 3> except for NB-IoT: 4> If the UE has radio link failure or handover failure information available in VarRLF-Report: 4> If this is the first RRCSetup received by the UE after declaring RLF / HOF and if the RPLMN is not included in plmn-IdentityList stored in VarRLF-Report: 5> sets firstReconnectionInDifferentPLMN in VarRLF-Report to valid; 5> if reconnectCellID in VarRLF-Report is not set 6> If the RPLMN is included in plmn-IdentityList stored in VarRLF-Report: 7> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover; 7> set eutraReconnectCellID in reconnectCellID in VarRLFReport to the global cell identity and PCell tracking area code; 5> if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report 6> include rlf-InfoAvailable; 1> sends the RRCConnectionSetupComplete message to the lower layers for transmission; 1> The procedure ends. *** End of 3GPP procedure text *** Figure 13, which includes Figures 13A-B, shows an ASN.1 data structure for a sample UEInformationResponse message that includes an IE RLF31 1758931 of 73 Report-r9 (shown in Figure 13B) according to the preceding example procedure text for LTE RRC. This IE includes an optional field firstReconnectionInDifferentPLMN-r16xy which, if present, indicates that the first cell in which the UE performed the RRC connection establishment after declaring RLF / HOF and not performing the reset belongs to a different PLMN than the plmnIdentityList stored in VarRLF-Report. In other implementations, a UE can include the reconnectCellID and timeUntilReconnection fields in an RLF report only when the first cell to which the UE reconnected after the RLF and subsequent failed reset belongs to a PLMN in plmn-IdentityList stored in the RLF report. Additionally, the UE can include an indicator in the RLF report when the reconnectCellID (included in the RLF report) is not the first cell to which the UE reconnected after the RLF and subsequent failed reset. These implementation methods can be illustrated by the following procedural text, which may form part of an NR RRC standard such as 3GPP TS 38.331 (v16.4.1). Note that this text may omit certain operations performed by the EU for the sake of brevity, and may be combined with the existing text in 3GPP TS 38.331 (v16.4.1). *** 3GPP procedure text begins *** The UE must perform the following actions after receiving the RRCSetup: 1> If the UE has radio link failure or handover failure information available in VarRLF-Report: 2> If reconnectCellID in VarRLF-Report is not set and if firstReconnectionInDifferentPLMN in VarRLF-Report is not set: 3> If the RPLMN is included in plmn-IdentityList stored in VarRLFReport: 4> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover; 4> set nrReconnectCellID in reconnectCellID in VarRLF-Report to the global cell identity and PCell tracking area code; 3> if not: 4> set firstReconnectionInDifferentPLMN in VarRLF-Report to valid; 1> if the UE supports RLF reporting for MRO NR inter-RAT as defined in TS 36.306

[62] , and if the UE has radio link failure or handover failure information 1758931 of 73 available in VarRLF-Report of TS 36.331

[10] : 2> If reconnectCellID in VarRLF-Report of TS 36.331

[10] is not set and if firstReconnectionInDifferentPLMN in VarRLF-Report of TS 36.331

[10] is not set: 3> if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report of TS 36.331

[10] : 4> set timeUntilReconnection in VarRLF-Report of TS 36.331

[10] to the time elapsed since the last radio link failure or handover failure in LTE; 4> set nrReconnectCellID in reconnectCellID in VarRLF-Report of TS 36.331

[10] to the global cell identity and PCell trace area code; 3> if not: 4> set firstReconnectionInDifferentPLMN in VarRLF-Report of TS 36.331

[10] to valid; 1> Send the RRCSetupComplete message to the lower layers for transmission, after which the procedure ends. *** End of 3GPP procedure text *** The sample message UEInformationResponse defined by the ASN.1 data structure shown in Figure 12 (described above) can be used with the sample procedure text above for NR RRC. These implementations can also be illustrated by the following procedural text, which may be part of an LTE RRC standard such as 3GPP TS 36.331 (v16.4.0). Note that this text may omit certain operations performed by the UE for the sake of brevity, and may be combined with the existing text in 3GPP TS 36.331 (v16.4.0). *** 3GPP procedure text begins *** The UE must [after receiving RRCConnectionSetup]: 1> except for NB-IoT: 2> if the UE supports the RLF report for EUTRA MRO inter-RAT as defined in TS 38.306

[87] , and if the UE has radio link failure or handover failure information available in VarRLF-Report of TS 38.331

[82] : 3> if reconnectCellID in VarRLF-Report of TS 38.331

[82] is not set 1758931 of 73 and if firstReconnectionInDifferentPLMN in VarRLF-Report of TS 38.331

[82] is not set: 4> if the RPLMN is included in plmn-IdentityList stored in VarRLFReport of TS 38.331

[82] 5> set timeUntilReconnection in VarRLF-Report of TS 38.331

[82] to the time elapsed since the last radio link failure or handover failure; 5> set eutraReconnectCellID in reconnectCellID in VarRLFReport of TS 38.331

[82] to the global cell identity and PCell trace area code; 4> if not: 5> set firstReconnectionInDifferentPLMN in VarRLF-Report of TS 38.331

[82] to valid; 1> Set the content of the RRCConnectionSetupComplete message as follows: 2> If the UE is connected to EPC: 3> except for NB-IoT: 4> If the UE has radio link failure or handover failure information available in VarRLF-Report: 4> If it is the first RRCSetup received by the UE after declaring RLF / HOF and if the RPLMN is not included in plmn-IdentityList stored in VarRLF-Report: 5> If reconnectCellID in VarRLF-Report is not set and if firstReconnectionInDifferentPLMN in VarRLF-Report is not set: 6> If the RPLMN is included in plmn-IdentityList stored in VarRLF-Report: 7> Set timeUntilReconnection in VarRLF-Report to the time elapsed since the last radio link failure or handover failure; 7> set eutraReconnectCellID in reconnectCellID in VarRLF-Report to the global cell identity and PCell tracking area code; 6> if not: 7> Set firstReconnectionInDifferentPLMN in VarRLFReport to valid; 1758931 of 73 5> if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report 6> include rlf-InfoAvailable; ... 1> sends the RRCConnectionSetupComplete message to the lower layers for transmission; 1> The procedure ends. * ** End of 3GPP procedure text *** The sample message UEInformationResponse defined by the ASN.1 data structure shown in Figure 13 (described above) can be used with the sample procedure text above for LTE RRC. In other implementations, a UE can include `timeUntilReconnection` in an RLF report regardless of whether the first cell to which the UE reconnected after the RLF and subsequent failed reset belongs to a PLMN in the `plmnIdentityList` stored in the RLF report. Furthermore, the UE can include an indicator in the RLF report when the `reconnectCellID` (included in the RLF report) is not the first cell to which the UE reconnected after the RLF and subsequent failed reset. These implementations have the advantage that the network node can determine, based on the contents of the RLF report, that `timeUntilReconnection` refers to the time the UE reconnected to a cell that does not belong to a PLMN in the `plmnIdentityList` stored in the RLF report. The implementations described above can be illustrated with reference to Figures 14-15, which show example methods (e.g., procedures) for a UE and a RAN node (RNN), respectively. In other words, several features of the operations described below correspond to various implementations described above. These example methods can be used together to provide various exemplary benefits and / or advantages. Although Figures 14-15 show specific blocks in a particular order, the operations of the respective methods can be performed in different orders and can be combined and / or divided into blocks with different functionality. Optional blocks or operations are indicated by dashed lines. In particular, Figure 14 shows a flowchart of an example method (e.g., procedure) for a user team to report failures of 1758931 of 73 link in a wireless network, according to various embodiments of this disclosure. The example method may be implemented by a UE (for example, a wireless device, an IoT device, a modem, etc., or a component thereof) as described elsewhere in this document. The example method may include operations in block 1420, where the UE can, after a link failure and a failed connection restoration on a first PLMN, connect to a first cell in the wireless network. The example method may also include operations in block 1440, where the UE can send a failure report to an RNN in the wireless network, including an indication of whether the first cell is associated with the first PLMN. In some embodiments, the link failure is an RLF or a HOF reported by the UE in the first PLMN, and the failure report is an RLF report. In some embodiments, the link failure occurred in a second cell associated with the first PLMN, and the restoration of the failed connection occurred in a third cell associated with the first PLMN. In some implementations, the example method may also include operations in block 1410, where the UE can, in response to a link failure, store a list of PLMN identifiers associated with a cell where the link failure occurred, including an identifier of the first PLMN. An example of such a list of identifiers is the plmn-IdentityList discussed earlier. In some of these implementations, the list of PLMN identifiers is included in the failure report. In some of these implementations, the RNN is part of at least one of the PLMNs identified in the list. In some of these implementations, the example method may also include operations in block 1430, where the user computer can determine whether the first cell (for example, the one the user computer has connected to) is associated with any of the PLMN identifiers in the list. The indication can be based on the result of this determination, according to different variations discussed below. In some variants, the indication includes the following: • an identifier for the first cell, when the first cell is associated with at least one PLMN identifier included in the list; and • no identifier for the first cell, when the first cell is not associated with any of the PLMN identifiers included in the list. In other variants, the indication includes 1758931 of 73 • an identifier of the first cell, and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the user equipment reconnected to the wireless network for the first time, following the link failure and failed connection restoration, on a PLMN that is not identified in the list. In other variants, the indication includes: • when the first cell is associated with at least one PLMN identifier included in the list, a first cell identifier, and an additional indication of the time elapsed between the link failure and the connection to the first cell; and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the UE reconnected to the wireless network for the first time, following the link failure and failed connection restoration, on a PLMN that is not identified in the list. In other variants, the indication includes: • an additional indication of the time elapsed between the link failure and the connection to the first cell; and • when the first cell is not associated with any of the identifiers of PLMNs included in the list indicate that the user equipment reconnected to the wireless network for the first time, following the link failure and failed connection restoration, on a PLMN that is not identified in the list. The ASN.1 data structures shown in Figures 12-13 can be used in conjunction with different from the variants described above. In addition, Figure 15 shows a flowchart of an example method (e.g., procedure) for a radio network node (RNN) in a wireless network to receive failure reports from UEs, according to various embodiments of this disclosure. The example method can be implemented by an RNN (e.g., a base station, an eNB, a gNB, an ng-eNB, an en-gNB, etc., or components thereof) as described elsewhere in this document. The example method may include block 1510 operations, where the RNN may receive, from a UE, a fault report that includes an indication of whether a first cell, to which the UE connected after a link failure and after a failed connection re-establishment on a first PLMN, is associated with the 1758931 of 73 first PLMN. In some embodiments, the link failure is an RLF or a HOF declared by the UE on the first PLMN, and the failure report is an RLF report. In some embodiments, the failure report includes a list of PLMN identifiers associated with a cell where the link failure occurred, including an identifier of the first PLMN. An example of such a list of identifiers is the plmn-IdentityList discussed earlier. In some of these embodiments, the RNN is part of at least one of the PLMNs identified in the list. In some embodiments, the link failure occurred in a second cell associated with the first PLMN, and the restoration of the failed connection occurred in a third cell associated with the first PLMN. In different variations, the indication may have any of the forms and / or contents discussed above in relation to the UE implementation forms of Figure 14. As mentioned above, the ASN.1 data structures shown in Figures 12-13 may be used in conjunction with different from these variations. In some embodiments, the example method may also include operations in block 1520, where the RNN can selectively adjust the mobility parameters for the first cell based on an indication. For example, these operations may be part of the SON functionality, which is described in more detail earlier. In some embodiments, the selective implementation of operations in block 1520 may include operations in sub-block 1521, where the RNN can refrain from adjusting the mobility parameters for the first cell when an indication shows that the first cell is not associated with the first PLMN in which the UE connection failure was re-established. Although the object described herein can be implemented in any appropriate system using any suitable component, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in Figure 16. For simplicity, the wireless network in Figure 16 represents only network 1606, network nodes 1660 and 1660b, and WDs 1610, 1610b, and 1610c. In practice, a wireless network may further include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or 1758931 of 73 any other network node or end device. Of the illustrated components, network node 1660 and wireless device (WD) 1610 are shown in additional detail. The wireless network can provide communication and other types of services to one or more wireless devices to facilitate access by wireless devices to and / or use of services provided by, or through, the wireless network. A wireless network can encompass and / or interact with any type of communication, telecommunications, data, cellular, and / or radio network, or other similar system. In some embodiments, a wireless network may be configured to operate according to specific standards or other predefined rules or procedures. Thus, certain wireless network embodiments may implement communication standards such as the Global System for Mobile Communications (GSM), the Universal System for Mobile Telecommunications (UMTS), Long-Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards such as IEEE 802.11; and / or any other suitable wireless communication standard such as the Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, and / or ZigBee standards. The 1606 network may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices. The 1660 network node and the WD 1610 comprise several components, which are described in more detail below. These components work together to provide network node and / or wireless device functionality, such as providing wireless connections in a wireless network. In various embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other component or system that can facilitate or participate in the communication of data and / or signals, whether through wired or wireless connections. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node B, evolved Node B (eNB), and NR Node B (gNB)). Base stations can be classified based on the amount of coverage they provide. 1758931 of 73 provide (or, in other words, their transmit power level) and may also be called femtobase stations, picobase stations, microbase stations, or macrobase stations. A base station may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) of the parts of a distributed radio base station, such as centralized digital units and / or remote radio units (RRUs), sometimes called remote radio heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an integrated antenna radio. The parts of a distributed radio base station may also be called nodes of a distributed antenna system (DAS). Other examples of network nodes include multi-standard radio equipment (MSRs), such as BS MSRs; network controllers, such as radio network controllers (RNCs) or base station controllers (BSCs); base transceiver stations (BTSs); transmission points; transmission nodes; multi-cell / multicast coordination entities (MCEs); core network nodes (e.g., MSCs, MMEs); operation and maintenance (O&M) nodes; operational service (OSS) nodes; sonar (SON) nodes; positioning nodes (e.g., E-SMLCs); and / or mobile device terminals (MDTs). As another example, a network node can be a virtual network node, as described in more detail below. More generally, however, network nodes can represent any suitable device (or group of devices) capable of being configured, arranged, and / or operable to enable and / or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network. In Figure 16, network node 1660 includes processing circuitry 1670, device-readable medium 1680, interface 1690, auxiliary equipment 1684, power supply 1686, power circuitry 1687, and antenna 1662. Although the network node 1660 illustrated in the example wireless network in Figure 16 may represent a device that includes the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components. It should be understood that a network node comprises any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods and / or procedures disclosed herein. Furthermore, while the components of network node 1660 are represented as individual boxes located within a larger box, or nested within multiple boxes, in practice, a network node may comprise 1758931 of 73 multiple different physical components that make up a single illustrated component (for example, the device readable medium 1680 may comprise multiple separate hard drives, as well as multiple RAM modules). Similarly, the 1660 network node can be composed of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In certain scenarios where the 1660 network node comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique pair of NodeB and RNC may, in some cases, be considered a single, separate network node. In some embodiments, the 1660 network node can be configured to support multiple Radio Access Technologies (RATs).In such embodiments, some components may be duplicated (for example, a separate device-readable medium 1680 for different RATs) and some components may be reused (for example, the same antenna 1662 may be shared by the RATs). The 1660 network node may also include multiple sets of the various components illustrated for different wireless technologies integrated into the 1660 network node, such as GSM, WCDMA, LTE, NR, Wi-Fi, or Bluetooth. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the 1660 network node. The 1670 processing circuitry can be configured to perform any determination, calculation, or similar operation (for example, certain acquisition operations) described herein as provided by a network node. These operations performed by the 1670 processing circuitry may include processing the information acquired by the 1670 processing circuitry by, for example, converting the acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and as a result of such processing, making a determination. The 1670 processing circuit may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, and application integrated circuit. 1758931 of 73 specific, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable to provide various functionalities of the 1660 network node, either alone or in conjunction with other components of the 1660 network node (for example, the 1680 device-readable medium). Such functionality may include any of the various wireless features, functions, or benefits discussed herein. For example, the processing circuit 1670 can execute instructions stored on the device-readable medium 1680 or in memory within the processing circuit 1670. In some embodiments, the processing circuit 1670 may include a system-on-a-chip (SoC). As a more specific example, the instructions (also referred to as a computer program product) stored on the medium 1680 may include instructions that, when executed by the processing circuit 1670, can configure the network node 1660 to perform operations corresponding to various example methods (e.g., procedures) described herein. In some embodiments, the 1670 processing circuits may include one or more of the 1672 radio frequency (RF) transceiver circuits and the 1674 baseband processing circuits. In some embodiments, the 1672 radio frequency (RF) transceiver circuits and the 1674 baseband processing circuits may be on separate chips (or chipsets), boards, or units, such as radio units and digital units. In other embodiments, some or all of the 1672 RF transceiver circuits and the 1674 baseband processing circuits may be on the same chip or chipset, board, or unit. In certain embodiments, some or all of the functionalities described herein as provided by a network node, base station, eNB, or other such network device may be performed by the 1670 processing circuitry by executing instructions stored on the 1680 device-readable medium or in memory within the 1670 processing circuitry. In alternative embodiments, some or all of the functionalities may be provided by the 1670 processing circuitry without executing instructions stored on a separate or discrete device-readable medium, such as via hardwired connections. In either of these embodiments, whether by executing instructions stored on a device-readable storage medium or 1758931 of 73 No, the 1670 processing circuitry can be configured to perform the described functionality. The benefits provided by this functionality are not limited to the 1670 processing circuitry alone or to other components of the 1660 network node, but are enjoyed by the 1660 network node as a whole, and / or by end users and the wireless network in general. Device-readable media 1680 may comprise any form of volatile or non-volatile computer-readable memory, including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard disk drive), removable storage media (e.g., a flash drive, a compact disc (CD), or a digital video disc (DVD)), and / or any other volatile or non-volatile, non-transient, computer-readable and / or executable memory devices that store information, data, and / or instructions that can be used by the processing circuit 1670.The device-readable medium 1680 can store any suitable instruction, data, or information, including a computer program, software, or application that includes one or more of the logic, rules, code, tables, etc., and / or other instructions capable of being executed by the processing circuit 1670 and used by the network node 1660. The device-readable medium 1680 can be used to store any calculations performed by the processing circuit 1670 and / or any data received through the interface 1690. In some embodiments, the processing circuitry 1670 and the device-readable medium 1680 can be considered integrated. Interface 1690 is used for wired or wireless signaling and / or data communication between network node 1660, network 1606, and / or WD 1610. As illustrated, interface 1690 comprises port(s) / terminal(s) 1694 for sending and receiving data, for example to and from network 1606 via a wired connection. The 1690 interface also includes radio front-end circuitry 1692, which can be coupled to, or in certain embodiments a portion of, the antenna 1662. The radio front-end circuitry 1692 comprises filters 1698 and amplifiers 1696. The radio front-end circuitry 1692 can be connected to the antenna 1662 and the processing circuitry 1670. The radio front-end circuitry can be configured to condition the signals communicated between the antenna 1662 and the processing circuitry 1670. The radio front-end circuitry 1692 can receive digital data. 1758931 of 73 that are to be sent to other network nodes or WD via a wireless connection. The radio front-end circuit 1692 can convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1698 and / or amplifiers 1696. The radio signal can then be transmitted via the antenna 1662. Similarly, when receiving data, the antenna 1662 can collect radio signals which are then converted into digital data by the radio front-end circuit 1692. The digital data can be passed to the processing circuitry 1670. In other embodiments, the interface may comprise different components and / or different combinations of components. In some alternative embodiments, the network node 1660 may not include separate radio front-end circuitry 1692; instead, the processing circuitry 1670 may comprise radio front-end circuitry and may be connected to the antenna 1662 without separate radio front-end circuitry 1692. Similarly, in some embodiments, all or part of the RF transceiver circuitry 1672 may be considered part of the interface 1690. In other embodiments, the interface 1690 may include one or more ports or terminals 1694, the radio front-end circuitry 1692, and the RF transceiver circuitry 1672, as part of a radio unit (not shown), and the interface 1690 may communicate with the baseband processing circuitry 1674, which is part of a digital unit (not shown). The 1662 antenna may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The 1662 antenna may be coupled to the 1690 radio front-end circuit and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, the 1662 antenna may comprise one or more omnidirectional, sector, or panel antennas operable for transmitting / receiving radio signals between, for example, 2 GHz and 66 GHz. An omnidirectional antenna may be used to transmit / receive radio signals in any direction, a sector antenna may be used to transmit / receive radio signals from devices within a particular area, and a panel antenna may be a line-of-sight antenna used to transmit / receive radio signals in a relatively straight line. In some cases, the use of more than one antenna may be referred to as MIMO.In certain embodiments, antenna 1662 may be separate from network node 1660 and may be connected to network node 1660 via an interface or port. Antenna 1662, interface 1690, and / or processing circuits 1670 may 1758931 of 73 can be configured to perform any receive operation and / or certain obtain operations described herein as performed by a network node. Any information, data, and / or signals can be received from a wireless device, another network node, and / or any other network equipment. Similarly, antenna 1662, interface 1690, and / or processing circuit 1670 can be configured to perform any transmit operation described herein as performed by a network node. Any information, data, and / or signals can be transmitted to a wireless device, another network node, and / or any other network equipment.The power circuitry 1687 may comprise, or be coupled to, power management circuitry and may be configured to supply power to the network node components 1660 to perform the functionality described herein. The power circuit 1687 may be powered by the power supply 1686. The power supply 1686 and / or the power circuits 1687 may be configured to provide power to the various network node components 1660 in a manner suitable for the respective components (e.g., at a voltage and current level required by each respective component). The power supply 1686 may be included in, or external to, the power circuit 1687 and / or the network node 1660.For example, network node 1660 can be connected to an external power source (e.g., a power outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source supplies power to power circuit 1687. As another example, power source 1686 can comprise a power source in the form of a battery or battery pack that is connected to, or integrated into, power circuit 1687. The battery can provide backup power in case the external power source fails. Other types of power sources, such as photovoltaic devices, can also be used. Alternative embodiments of the 1660 network node may include additional components beyond those shown in Figure 16 that may be responsible for providing certain aspects of the network node's functionality, including any of the functionalities described herein and / or any functionality necessary to support the object described herein. For example, the 1660 network node may include user interface equipment to enable and / or facilitate the input of information into the 1660 network node and to enable and / or facilitate the output of information from the 1660 network node. This may 1758931 of 73 allow and / or facilitate a user the way to perform diagnoses, maintenance, repair and other administrative functions for network node 1660. In some embodiments, a wireless device (WD, for example, the WD 1610) can be configured to transmit and / or receive information without direct human interaction. For example, a WD device can be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to network requests.Examples of a WD include, but are not limited to, smartphones, mobile phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, customer premises wireless equipment (CPE), mobile-type communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, etc. A Device Warehouse (WD) can support device-to-device (D2D) communication, for example, by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X), and in this case, it can be called a D2D communication device. As another specific example, in an Internet of Things (IoT) scenario, a WD can represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another WD and / or a network node. The WD in this case can be a machine-to-machine (M2M) device, which in a 3GPP context can be called an MTC device. As a particular example, the WD can be a Unit Enabled (UE) implementing the 3GPP Narrowband Internet of Things (NB-IoT) standard.Specific examples of such machines or devices are sensors, measuring devices such as energy meters, industrial machinery, or household appliances or personal devices (e.g., refrigerators, televisions, etc.) and personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment capable of monitoring and / or reporting its operational status or other functions associated with its operation. A DT as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a DT such as the... 1758931 of 73 described above may be mobile, in which case it may also be called a mobile device or mobile terminal. As illustrated, the WD 1610 wireless device includes the antenna 1611, the interface 1614, the processing circuitry 1620, the device-readable medium 1630, the user interface equipment 1632, the auxiliary equipment 1634, the power supply 1636, and the power circuitry 1637. The WD 1610 may include multiple sets of one or more of the illustrated components for different wireless technologies supported by the WD 1610, such as GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth, to name a few. These wireless technologies may be integrated on the same or different chips or chipsets as other components within the WD 1610. Antenna 1611 may include one or more antennas or antenna arrays, configured to send and / or receive wireless signals, and is connected to interface 1614. In certain alternative embodiments, antenna 1611 may be separate from WD 1610 and connectable to WD 1610 via an interface or port. Antenna 1611, interface 1614, and / or processing circuitry 1620 may be configured to perform any receive or transmit operation described herein as performed by a WD. Any information, data, and / or signals may be received from a network node and / or another WD. In some embodiments, the front-end radio circuitry and / or antenna 1611 may be considered an interface. As illustrated, interface 1614 comprises a radio front-end circuit 1612 and an antenna 1611. The radio front-end circuits 1612 comprise one or more filters 1618 and amplifiers 1616. The radio front-end circuitry 1614 is connected to the antenna 1611 and the processing circuitry 1620 and can be configured to condition the signals communicated between the antenna 1611 and the processing circuitry 1620. The radio front-end circuitry 1612 may be coupled to or form part of the antenna 1611. In some embodiments, the WD 1610 may not include a separate radio front-end circuitry 1612. Rather, the processing circuitry 1620 may comprise a radio front-end circuitry and may be connected to the antenna 1611. Similarly, in some embodiments, part or all of the RF transceiver circuitry 1622 may be considered a part of the interface 1614.The 1612 radio front-end circuitry can receive digital data that will be sent to other network nodes or WD via a wireless connection. The radio front-end circuit 1612, part 1758931, can convert digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1618 and / or amplifiers 1616. The radio signal can then be transmitted via antenna 1611. Similarly, when receiving data, antenna 1611 can collect radio signals which are then converted into digital data by the radio front-end circuit 1612. The digital data can then be passed to the processing circuitry 1620. In other embodiments, the interface may comprise different components and / or different combinations of components. The 1620 processing circuit may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable to provide the functionality of the WD 1610, either alone or in combination with other components of the WD 1610, such as the device-readable media 1630. Such functionality may include any of the various wireless features or benefits discussed herein. For example, the processing circuit 1620 can execute instructions stored on the device-readable medium 1630 or in memory within the processing circuit 1620 to provide the functionality disclosed herein. More specifically, the instructions (also referred to as computer program product) stored on the medium 1630 can include instructions that, when executed by the processor 1620, can configure the wireless device 1610 to perform operations corresponding to various example methods (e.g., procedures) described herein. As illustrated, the 1620 processing circuitry includes one or more of the 1622 RF transceiver circuits, the 1624 baseband processing circuitry, and the 1626 application processing circuitry. In other embodiments, the processing circuitry may comprise different components and / or different combinations of components. In certain embodiments, the 1620 processing circuitry of the WD 1610 may comprise a System-on-a-Chip (SOC). In some embodiments, the 1622 RF transceiver circuitry, the 1624 baseband processing circuitry, and the 1626 application processing circuitry may be on separate chips or chipsets. In alternative embodiments, some or all of the 1624 baseband processing circuitry and the circuitry of 1758931 of 73 Application Processing 1626 may be combined on one chip or chipset, and the RF transceiver circuitry 1622 may be on a separate chip or chipset. In other alternative embodiments, some or all of the RF transceiver circuitry 1622 and the baseband processing circuitry 1624 may be on the same chip or chipset, and the application processing circuitry 1626 may be on a separate chip or chipset. In other alternative embodiments, some or all of the RF transceiver circuitry 1622, the baseband processing circuitry 1624, and the application processing circuitry 1626 may be combined on the same chip or chipset. In some embodiments, the RF transceiver circuitry 1622 may be part of the interface 1614.The RF transceiver circuitry 1622 can condition the RF signals for the processing circuitry 1620. In certain embodiments, some or all of the functionalities described herein as performed by a WD can be provided by the processing circuitry 1620 executing instructions stored on the device-readable medium 1630, which in certain embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionalities can be provided by the processing circuitry 1620 without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In either of these particular embodiments, whether or not executing instructions stored on a device-readable storage medium, the processing circuitry 1620 can be configured to perform the described functionality.The benefits provided by this functionality are not limited to the 1620 processing circuitry alone or other components of the WD 1610, but are enjoyed by the WD 1610 as a whole, and / or by end users and the wireless network in general. The 1620 processing circuitry can be configured to perform any determination, calculation, or similar operation (e.g., certain extraction operations) described herein as being performed by a WD. These operations, performed by the 1620 processing circuit, may include processing the information extracted by the 1620 processing circuit, for example, converting the extracted information into other information, comparing the extracted or converted information with information stored by the WD 1610, and / or performing one or more operations based on the extracted or 1758931 of 73 the converted information, and as a result of said processing making a determination. The device-readable medium 1630 may be operable for storing a computer program, software, or application that includes one or more of the logic, rules, codes, tables, etc., and / or other instructions capable of being executed by the processing circuit 1620. The device-readable medium 1630 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage medium (e.g., a hard disk), removable storage medium (e.g., a compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile, non-transient, readable and / or executable memory devices that store information, data, and / or instructions that can be used by the processing circuit 1620.In some embodiments, the processing circuitry 1620 and the device-readable medium 1630 can be considered integrated. The 1632 user interface equipment may include components that enable and / or facilitate a human user to interact with the WD 1610. Such interaction can take many forms, such as visual, auditory, tactile, etc. The 1632 user interface equipment may be operable to produce output for the user and to enable and / or facilitate the user to provide input to the WD 1610. The type of interaction may vary depending on the type of 1632 user interface equipment installed on the WD 1610. For example, if the WD 1610 is a smartphone, the interaction may be through a touchscreen; if the WD 1610 is a smart meter, the interaction may be through a display that provides usage (for example, the number of gallons used) or a speaker that provides an audible alert (for example, if smoke is detected).The 1632 user interface equipment may include input interfaces, devices, and circuitry, and output interfaces, devices, and circuitry. The 1632 user interface equipment may be configured to enable and / or facilitate the input of information into the WD 1610 and is connected to the 1620 processing circuitry to enable and / or facilitate the processing circuitry 1620 to process the input information. The 1632 user interface equipment may include, for example, a microphone, a proximity sensor or other sensor, keys / buttons, a touchscreen, one or more cameras, a USB port, or other input circuitry. The 1632 user interface equipment is also configured to enable and / or facilitate the output of information from the WD 1610, and to enable and / or facilitate the processing circuitry. 1758931 of 73 processing 1620 emits information from the WD 1610. The user interface equipment 1632 may include, for example, a speaker, a display, vibration circuitry, a USB port, a headphone interface, or other output circuitry. By using one or more input / output interfaces, devices, and circuitry of the user interface equipment 1632, the WD 1610 can communicate with end users and / or the wireless network and enable and / or facilitate their benefiting from the functionality described herein. The 1634 auxiliary equipment is operable to provide more specific functionality that may not be typically performed by the WD. It may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication, such as wired communications, etc. The inclusion and type of components of the 1634 auxiliary equipment may vary depending on the implementation and / or the scenario.The power source 1636 may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., a wall outlet), photovoltaic devices, or energy cells, may also be used. The WD 1610 may further comprise power circuitry 1637 for supplying power from the power source 1636 to the various parts of the WD 1610 that require power from the power source 1636 to perform any functionality described or indicated herein. The power circuitry 1637 may, in certain embodiments, comprise power management circuitry.The power circuitry 1637 may additionally or alternatively be operable to receive power from an external power source; in which case the WD 1610 may be connected to the external power source (such as a wall outlet) via the input circuitry or an interface such as a power cable. The power circuitry 1637 may also, in certain embodiments, be operable to deliver power from an external power source to the power supply 1636. This may be, for example, for charging the power supply 1636. The power circuitry 1637 may perform any conversion or other modification to the power of the power supply 1636 to make it suitable for supplying the respective components of the WD 1610. Figure 17 illustrates one embodiment of a user device according to several aspects described in this document. As used in this document, a user device or UE may not necessarily have a 1758931 of 73 user in the sense of a human user who owns and / or operates the relevant device. Instead, a user equipment may represent a device intended to be sold to or operated by a human user, but which may not be, or may not initially be, associated with a specific human user (for example, a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale or operation by an end user, but which may be associated with or operated for the benefit of a user (for example, a smart energy meter). UE 17200 may be any UE identified by the Third Generation Partnership Project (3GPP), including an NB-IoT UE, a machine-type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.The UE 1700, as illustrated in Figure 17, is an example of a WD configured for communication according to one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as the 3GPP GSM, UMTS, LTE, and / or 5G standards. As mentioned previously, the terms WD and UE can be used interchangeably. Therefore, although Figure 17 is a UE, the components discussed here are equally applicable to a WD, and vice versa. In Figure 17, the user equipment 1700 includes processing circuitry 1701 that is operatively coupled to the input / output interface 1705, the radio frequency (RF) interface 1709, the network connection interface 1711, memory 1715 including random access memory (RAM) 1717, read-only memory (ROM) 1719, and storage medium 1721 or the like, the communication subsystem 1731, the power supply 1733, and / or any other component, or any combination thereof. The storage medium 1721 includes the operating system 1723, the application program 1725, and the data 1727. In other embodiments, the storage medium 1721 may include other similar types of information. Some user teams may use all the components shown in Figure 17, or only a subset of them. The level of integration between components may vary from one user team to another.In addition, some user equipment may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. In Figure 17, the 1701 processing circuit can be configured to process computer instructions and data. The 1701 processing circuit can be configured to implement any operational sequential state machine to execute machine instructions stored as computer programs. 1758931 of 73 machine-readable data in memory, such as one or more state machines implemented in hardware (for example, in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored programs; general-purpose processors, such as a microprocessor or a digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuit 1701 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer. In the embodiment shown, the 1705 input / output interface can be configured to provide a communication interface with an input device, an output device, or an input / output device. The UE 1700 device can be configured to use an output device via the 1705 input / output interface. An output device can use the same type of interface port as an input device. For example, a USB port can be used to provide both input and output to the UE 1700 device. The output device can be a speaker, sound card, video card, display, monitor, printer, actuator, transmitter, smart card, another output device, or any combination thereof.The UE 1700 device can be configured to use an input device via the 1705 input / output interface to enable and / or facilitate user input to the UE 1700. The input device can include a touch or presence-sensitive display, a camera (e.g., a digital camera, digital video camera, webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display can include a capacitive or resistive touch sensor to detect user input. A sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, another similar sensor, or any combination thereof.For example, the input device could be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor. In Figure 17, the RF interface 1709 can be configured to provide a communication interface to RF components, such as a transmitter, receiver, and antenna. The network connection interface 1711 can be configured to provide a communication interface to the 1743a network. The 1743a network can encompass wired and / or wireless networks such as a local area network (LAN), a network of 1758931 of 73 wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, network 1743a may comprise a Wi-Fi network. The network connection interface 1711 may be configured to include a receiver interface and a transmitter interface used to communicate with one or more devices across a communication network in accordance with one or more communication protocols, such as Ethernet, TCP / IP, SONET, ATM, or similar. The network connection interface 1711 may implement receiver and transmitter functionality appropriate to the communication network links (e.g., optical, electrical, and similar). The transmitter and receiver functions may share circuit components, software, or firmware, or alternatively, they may be implemented separately. The 1717 RAM can be configured to interface via the 1702 bus with the 1701 processing circuitry to provide storage or caching of data or computer instructions during the execution of software programs such as the operating system, application programs, and device drivers. The 1719 ROM can be configured to provide computer instructions or data to the 1701 processing circuitry. For example, the 1719 ROM can be configured to store low-level, unchanging system code or data for basic system functions, such as basic input / output (I / O), booting, or receiving keystrokes stored in non-volatile memory.The 1721 storage medium can be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives. In one example, storage medium 1721 may be configured to include operating system 1723; application program 1725, such as a web browser application, a widget or gadget engine, or another application; and data file 1727. Storage medium 1721 may store, for use by user computer 1700, any of a variety of operating systems or combinations of operating systems. For example, application program 1725 may include executable program instructions (also called a computer program product) that, when executed by processor 1701, may configure UE computer 1700 to perform operations corresponding to various example methods (for example, procedures) described herein. 1758931 of 73 The 1721 storage medium can be configured to include a variety of physical disk drives, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a high-density digital versatile disc (HD-DVD) optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini-dual in-line memory module (DIMM), synchronous dynamic random-access memory (SDRAM), an external micro-DIMM SDRAM, smart card memory such as a subscriber identity module or removable user identity module (SIM / RUIM), other memory, or any combination thereof.Storage medium 1721 may enable and / or facilitate UE 1700 access to computer executable instructions, application programs, or similar items stored on transient or non-transient memory media, for downloading or loading data. A manufactured item, such as one using a communication system, may be tangibly incorporated into storage medium 1721, which may comprise a device-readable medium. In Figure 17, the processing circuit 1701 can be configured to communicate with network 1743b using communication subsystem 1731. Network 1743a and network 1743b can be the same network, multiple networks, or different networks. Communication subsystem 1731 can be configured to include one or more transceivers used to communicate with network 1743b. For example, communication subsystem 1731 can be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication, such as another WD, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE 802.17, CDMA, WCDMA, GSM, LTE, UTRAN, WiMAX, or similar protocols.Each transceiver may include the 1733 transmitter and / or the 1735 receiver to implement the transmitter or receiver functionality, respectively, appropriate to the RAN links (e.g., frequency allocations and the like). Furthermore, the 1733 transmitter and 1735 receiver of each transceiver may share circuit components, software, or firmware, or alternatively, they may be implemented separately. In the illustrated embodiment, the communication functions of the 1731 communication subsystem may include data communication, voice communication, multimedia communication, and short-range communications. 1758931 of 73, such as Bluetooth, near-field communication, location-based communication like using the Global Positioning System (GPS) to determine a location, other similar communication functions, or any combination thereof. For example, the communication subsystem 1731 might include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 1743b might encompass wired and / or wireless networks such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, other similar networks, or any combination thereof. For example, the network 1743b might be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 1713 might be configured to provide alternating current (AC) or direct current (DC) to the UE 1700 components. The features, advantages, and / or functions described herein can be implemented in one of the UE 1700 components or distributed among several UE 1700 components. Furthermore, the features, advantages, and / or functions described herein can be implemented in any combination of hardware, software, or firmware. For example, the 1731 communication subsystem can be configured to include any of the components described herein. Additionally, the 1701 processing circuit can be configured to communicate with any of these components via the 1702 bus. In another example, any of these components can be represented by program instructions stored in memory that, when executed by the 1701 processing circuits, perform the corresponding functions described herein.In another example, the functionality of any of these components can be divided between the processing circuitry 1701 and the communication subsystem 1731. In another example, the non-computation-intensive functions of any of these components can be implemented in software or firmware, and the computation-intensive functions can be implemented in hardware. Figure 18 is a schematic block diagram illustrating an 1800 virtualization environment where functions implemented by certain embodiments can be virtualized. In this context, virtualization means creating virtual versions of appliances or devices, which may include the virtualization of hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device, or any other type of 1758931 of 73 communication device) or its components, and refers to an implementation in which at least part of the functionality is implemented as one or more virtual components (for example, through one or more applications, components, functions, virtual machines or containers running on one or more physical processing nodes on one or more networks). In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines deployed in one or more 1800 virtual environments hosted by one or more of the 1830 hardware nodes. Furthermore, in embodiments where the virtual node is not a radio access node or does not require radio connectivity (for example, a core network node), then the network node may be fully virtualized. The functions may be implemented by one or more 1820 applications (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operating to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. The 1820 applications run in the 1800 virtualization environment provided by the 1830 hardware comprising the 1860 processing circuitry and the 1890 memory. The 1890 memory contains 1895 instructions executable by the 1860 processing circuitry, by which the 1820 application is operational to provide one or more of the features, benefits, and / or functions disclosed herein. The 1800 virtualization environment may include 1830 general-purpose or special-purpose network hardware devices (or nodes) comprising a set of one or more 1860 processors or processing circuits, which may be off-the-shelf (COTS) commercial processors, dedicated Application-Specific Integrated Circuits (ASICs), or any other type of processing circuitry that includes digital or analog hardware components or special-purpose processors. Each hardware device may comprise 1890-1 memory, which may be non-persistent memory for temporarily storing 1895 instructions or software executed by the 1860 processing circuits.For example, the 1895 instructions may include program instructions (also called computer program product) that, when executed by the 1860 processing circuitry, may configure the 1820 hardware node to perform operations corresponding to various example methods (e.g., 1758931 of 73 procedures) described in this document. These operations can also be attributed to virtual node(s) 1820 that is hosted on hardware node 1830. Each hardware device may comprise one or more 1870 network interface controllers (NICs), also known as network interface cards, which include the 1880 physical network interface. Each hardware device may also include non-transient, persistent, machine-readable 1890-2 storage media that have stored therein software 1895 and / or instructions executable by processing circuits 1860. The 1895 software may include any type of software, including software for instantiating one or more 1850 virtualization layers (also called hypervisors), software for running virtual machines 1840, as well as software that enables the execution of functions, features, and / or benefits described in connection with some embodiments described herein. Virtual machines 1840 comprise virtual processing, virtual memory, a virtual network or interface, and virtual storage, and can be run by a corresponding 1850 virtualization layer or hypervisor. Different implementations of the 1820 virtual appliance instance can be deployed on one or more 1840 virtual machines, and these implementations can be carried out in various ways. During operation, the 1860 processing circuitry runs the 1895 software to instantiate the 1850 hypervisor or virtualization layer, which may sometimes be referred to as a virtual machine monitor (VMM). The 1850 virtualization layer can present the 1840 virtual machine with a virtual operating platform that appears as network hardware. As shown in Figure 18, 1830 hardware can be a standalone network node with generic or specific components. 1830 hardware can include the 18225 antenna and can implement some functions through virtualization. Alternatively, 1830 hardware can be part of a larger hardware cluster (for example, in a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed through 18100 Management and Orchestration (MANO), which, among other things, oversees the lifecycle management of 1820 applications. Hardware virtualization is sometimes called network function virtualization (NFV). NFV can be used to consolidate many types of 1758931 of 73 network equipment in industry standard high-volume server hardware, physical switches and physical storage, which may be located in data centers, and equipment on customer premises. In the context of NFV, an 1840 virtual machine can be a software implementation of a physical machine that runs programs as if they were running on a non-virtualized physical machine. Each 1840 virtual machine, and the portion of 1830 hardware that runs that virtual machine—whether dedicated hardware and / or hardware shared with other 1840 virtual machines—forms a separate virtual network element (VNE). Still within the context of NFV, the virtual network function (VNF) is responsible for handling specific network functions that run on one or more virtual machines 1840 over the hardware network infrastructure 1830 and corresponds to application 1820 in Figure 18. In some embodiments, one or more 18200 radio units, each comprising one 18220 transmitter and one or more 18210 receiver, may be coupled to one or more 18225 antennas. The 18200 radio units may communicate directly with the 1830 hardware nodes via one or more suitable network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. Nodes arranged in this manner may also communicate with one or more UEs, as described elsewhere herein. In some embodiments, certain signaling may be carried out via the 18230 control system, which may alternatively be used for communication between the 1830 hardware nodes and the 18200 radio units. With reference to Figure 19, according to one embodiment, a communication system includes the telecommunications network 1910, such as a 3GPP-type cellular network, comprising the access network 1911, such as a radio access network, and the core network 1914. The access network 1911 comprises a plurality of base stations 1912a, 1912b, 1912c, such as NB, eNB, gNB, or other types of wireless access points, each of which defines a corresponding coverage area 1913a, 1913b, 1913c. Each base station 1912a, 1912b, 1912c can connect to the core network 1914 via a wired or wireless connection 1915. A first user device 1991 located in the coverage area 1913c can be configured to connect wirelessly to, or be called by, the corresponding base station 1912c. A second user device 1992 located in the area 1758931 of 73 coverage 1913a can connect wirelessly to the corresponding base station 1912a. Although this example illustrates a plurality of user equipment 1991, 1992, the disclosed embodiments are equally applicable to a situation in which a single user equipment is in the coverage area or in which a single user equipment connects to [...] The telecommunications network 1910 is in turn connected to the host computer 1930, which may be incorporated into the hardware and / or software of a standalone server, a cloud-deployed server, a distributed server, or as processing resources in a server farm. The host computer 1930 may be owned or controlled by a service provider or may be operated by or on behalf of the service provider. The connections 1921 and 1922 between the telecommunications network 1910 and the host computer 1930 may extend directly from the core network 1914 to the host computer 1930 or may pass through an optional intermediate network 1920. The intermediate network 1920 may be one or a combination of more than one public, private, or hosted network; the intermediate network 1920, if any, may be a backbone or the Internet; in particular, the intermediate network 1920 may comprise two or more subnets (not shown). The communication system in Figure 19 as a whole enables connectivity between the connected user equipment 1991, 1992 and the host computer 1930. This connectivity can be described as an over-the-top (OTT) connection 1950. The host computer 1930 and the connected user equipment 1991, 1992 are configured to communicate data and / or signaling over the OTT connection 1950, using as intermediaries the access network 1911, the core network 1914, any intermediate networks 1920, and other possible infrastructures (not shown). The OTT connection 1950 can be transparent in the sense that the participating communication devices through which the OTT connection 1950 passes are unaware of the uplink and downlink communication routing.For example, base station 1912 may not be informed, or need not be, about the past routing of an incoming downlink communication with data originating from host computer 1930 to be forwarded (e.g., delivered) to a connected UE 1991. Similarly, base station 1912 does not need to be informed about the future routing of an outgoing uplink communication originating from user equipment 1991 to host computer 1930. The following will describe implementation examples, according to one embodiment, of the user equipment, the base station, and the host computer that Items 1758931 of 73 have been discussed in the preceding paragraphs, with reference to Figure 20. In the communication system 2000, the host computer 2010 comprises hardware 2015 that includes a communication interface 2016 configured to establish and maintain a wired or wireless connection with an interface of a communication device other than the communication system 2000. The host computer 2010 further comprises processing circuits 2018, which may have storage and / or processing capabilities. In particular, the processing circuits 2018 may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The host computer 2010 further comprises software 2011, which is stored on or accessible by the host computer 2010 and is executable by the processing circuits 2018.Software 2011 includes Host Application 2012. Host Application 2012 can be used to provide a service to a remote user, such as UE 2030, which connects via OTT Connection 2050 terminating at UE 2030 and Host Computer 2010. When providing service to the remote user, Host Application 2012 can provide user data transmitted via OTT Connection 2050. The communication system 2000 may also include the base station 2020 provided in a telecommunications system and comprising the hardware 2025 that enables it to communicate with the host computer 2010 and the user equipment 2030. The hardware 2025 may include a communication interface 2026 for establishing and maintaining a wired or wireless connection with an interface of a communication device other than the communication system 2000, as well as a radio interface 2027 for establishing and maintaining at least one wireless connection 2070 with the user equipment 2030 located within a coverage area (not shown in Figure 20) served by the base station 2020. The communication interface 2026 may be configured to facilitate the connection 2060 with the host computer 2010.The connection 2060 can be direct, or it can pass through a core network (not shown in Figure 20) of the telecommunications system and / or through one or more intermediate networks outside the telecommunications system. In the embodiment shown, the hardware 2025 of the base station 2020 can also include processing circuitry 2028, which can comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. 1758931 of 73 The 2020 base station also includes the 2021 software, which is stored internally or accessible via an external connection. For example, the 2021 software may include program instructions (also referred to as computer program product) that, when executed by the 2028 processing circuits, can configure the 2020 base station to perform operations corresponding to various example methods (e.g., procedures) described herein. The communication system 2000 may also include the aforementioned UE 2030, whose hardware 2035 may include the radio interface 2037 configured to establish and maintain the wireless connection 2070 with a base station serving a coverage area in which the UE 2030 is currently located. The hardware 2035 of the UE 2030 may also include processing circuitry 2038, which may comprise one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The UE 2030 also includes the 2031 software, which is stored in or accessible from the UE 2030 and is executable by the 2038 processing circuits. The 2031 software includes the 2032 client application. The 2032 client application can be used to provide a service to a human or non-human user through the UE 2030, with support from the 2010 host computer. On the 2010 host computer, a running 2012 host application can communicate with the running 2032 client application via the 2050 OTT connection, which terminates at the UE 2030 and the 2010 host computer. When providing the service to the user, the 2032 client application can receive request data from the 2012 host application and provide user data in response to the request data. The 2050 OTT connection can transfer both the request data and the user data.The client application 2032 can interact with the user to generate the user data it provides. Software 2031 can also include program instructions (also called computer program product) that, when executed by processing circuit 2038, can configure UE 2030 to perform operations corresponding to various example methods (e.g., procedures) described herein. It is observed that the host computer 2010, base station 2020, and user equipment 2030 illustrated in Figure 20 may be similar or identical to the host computer 1930, one of the base stations 1912a, 1912b, 1912c, and one of the 1758931 of 73 user equipment 1991, 1992 of Figure 196, respectively. That is, the internal operation of these entities can be as shown in Figure 20 and independently, the surrounding network topology can be that of Figure 19. In Figure 20, the OTT connection 2050 is drawn abstractly to illustrate communication between host computer 2010 and user computer 2030 via base station 2020, without explicitly referencing any intermediary devices or the precise routing of messages through these devices. The network infrastructure can determine the routing, which can be configured to hide it from UE 2030, the service provider operating host computer 2010, or both. While the OTT connection 2050 is active, the network infrastructure can also make decisions that dynamically change the routing (for example, based on load balancing or network reconfiguration). The 2070 wireless connection between the 2030 UE and the 2020 base station is consistent with the embodiments described throughout this disclosure. One or more of the various embodiments enhance the performance of OTT services provided to the 2030 UE using the 2050 OTT connection, in which the 2070 wireless connection forms the final segment. More specifically, the embodiments disclosed herein can improve network flexibility for monitoring end-to-end Quality of Service (QoS) of data streams, including their corresponding radio carriers, associated with data sessions between a user equipment (UE) and another entity, such as an OTT data application or a service external to the 5G network. These and other advantages can facilitate more timely design, implementation, and deployment of 5G / NR solutions.Furthermore, these implementation methods can facilitate flexible and timely control of the quality of service of data sessions, which can lead to improvements in capacity, performance, latency, etc., anticipated by 5G / NR and important for the growth of OTT services. A measurement procedure may be provided to monitor data rate, latency, and other operational aspects of the network where one or more implementations are improved. An optional network functionality may also be provided to reconfigure the OTT 2050 connection between the host computer 2010 and the UE 2030 in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT 2050 connection may be implemented in the computer's software 2011 and hardware 2015. 1758931 of 73 host 2010 or in the software 2031 and hardware 2035 of the UE 2030, or both. In the embodiments, the sensors (not shown) may be deployed in or in association with the communication devices through which the OTT connection 2050 passes; the sensors may participate in the measurement procedure by supplying values ​​of the monitored quantities exemplified above, or by supplying values ​​of other physical quantities from which the software 2011, 2031 may calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 2050 may include the message format, relay settings, preferred routing, etc.; the reconfiguration need not affect the base station 2020, and may be unknown or imperceptible to the base station 2020. Such procedures and functionalities may be known and practiced in the art.In certain implementations, the measurements may involve user equipment signaling that facilitates measurements of performance, propagation times, latency, and the like from the 2010 host computer. The measurements may be implemented so that the 2011 and 2031 software causes messages, particularly empty or "dummy" messages, to be transmitted using the 2050 OTT connection while monitoring propagation times, errors, etc. Figure 21 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to one embodiment. The communication system includes a host computer, a base station, and user equipment, which, in some embodiments, may be those described with reference to other figures in this document. For the sake of simplicity, only references to Figure 21 will be included in this section. In step 2110, the host computer provides the user data. In substep 2111 (which may be optional) of step 2110, the host computer provides the user data by running a core application. In step 2120, the host computer initiates a transmission that carries the user data to the UE.In step 2130 (which may be optional), the base station transmits to the UE the user data that was carried in the transmission initiated by the host computer, in accordance with the embodiments described throughout this disclosure. In step 2140 (which may also be optional), the user computer runs a host application associated with the host application running on the host computer. Figure 22 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to one embodiment. The communication system includes a host computer and a workstation. 1758931 of 73 base and a user equipment that may be those described with reference to other figures in this document. To simplify this disclosure, only references to Figure 22 will be included in this section. In step 2210 of the method, the host computer provides the user data. In an optional substep (not shown), the host computer provides the user data by running a core application. In step 2220, the host computer initiates a transmission that carries the user data to the UE. The transmission may pass through the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2230 (which may be optional), the user equipment receives the user data carried in the transmission. Figure 23 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to one embodiment. The communication system includes a host computer, a base station, and user equipment, which may be those described with reference to other figures in this document. For the sake of simplicity, this section will only include references to Figure 23. In step 2310 (which may be optional), the user equipment receives input data from the host computer. Alternatively, in step 2320, the user equipment provides user data. In substep 2321 (which may be optional) of step 2320, the user equipment provides user data by running a host application.In substep 2311 (which may be optional) of step 2310, the UE executes a host application that provides user data in response to input data received by the host computer. When providing user data, the executed host application may also consider information received from the user. Regardless of how the user data was provided, the UE initiates, in substep 2330 (which may be optional), the transmission of the user data to the host computer. In step 2340 of the method, the host computer receives the user data transmitted from the user computer, in accordance with the embodiments described throughout this disclosure. Figure 24 is a flowchart illustrating an example method and / or procedure implemented in a communication system, according to one embodiment. The communication system includes a host computer, a base station, and user equipment, which may be those described with reference to other figures in this document. To simplify this disclosure, only references to Figure 24 will be included in this section. In step 2410 (which may be optional), of 1758931 of 73 In accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 2420 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 2430 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station. The foregoing only illustrates the principles of disclosure. Various modifications and alterations of the described embodiments will be evident to those skilled in the art in light of the teachings presented here. It will therefore be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures which, although not explicitly shown or described herein, incorporate the principles of disclosure and may thus fall within the spirit and scope of disclosure. Various embodiments may be used together, as well as interchangeably, as should be understood by those of ordinary knowledge of the art. The term unit, as used herein, may have a conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, solid-state and / or discrete logic devices, computer programs or instructions for carrying out the respective tasks, procedures, calculations, outputs and / or display functions, etc., such as those described herein. All appropriate steps, methods, features, functions, or benefits disclosed herein may be implemented through one or more functional units or modules of one or more virtual appliances. Each virtual appliance may comprise a number of such functional units. These functional units may be implemented through processing circuitry, which may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, and so forth.The program code stored in memory includes program instructions to execute one or more protocols. 1758931 of 73 telecommunications and / or data communications, as well as instructions for carrying out one or more of the techniques described herein. In some implementations, processing circuitry may be used to make the respective functional unit perform the corresponding functions according to one or more embodiments of this disclosure. As described herein, the device and / or apparatus may be represented by a semiconductor chip, a chipset, or a module (hardware) comprising such a chip or chipset; however, this does not preclude the possibility that a device or apparatus's functionality, instead of being implemented in hardware, may be implemented as a software module, such as a computer program or a computer program product comprising executable portions of software code for execution on a processor. Furthermore, the functionality of a device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and / or apparatuses, whether functionally cooperating or operating independently of one another.Furthermore, devices and appliances can be deployed in a distributed manner within a system, provided that the functionality of the device or appliance is maintained. These and similar principles are considered to be known by an expert. Furthermore, the functions described herein as being performed by a wireless device or network node may be distributed among a plurality of wireless devices and / or network nodes. In other words, the network node and wireless device functions described herein are not limited to being performed by a single physical device and may, in fact, be distributed among several physical devices. Furthermore, certain terms used in this disclosure, including the specification, drawings, and embodiments, may be used synonymously in certain cases, including, but not limited to, for example, data and information. It should be understood that while these words and / or other words that may be synonymous with each other may be used synonymously herein, there may be instances where such words are not intended to be used synonymously. In addition, to the extent prior art knowledge has not been explicitly incorporated by reference herein, it is explicitly incorporated herein in its entirety. All publications referenced herein are incorporated herein by reference in their entirety. 1758931 of 73 Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by a person skilled in the art to which this disclosure pertains. It is further understood that terms used herein should be interpreted in a way that is consistent with their meaning in the context of this specification and the relevant art, and not in an idealized or overly formal sense unless expressly defined herein. Furthermore, certain terms used in this disclosure, including the descriptive report and drawings, may be used synonymously in some cases (e.g., “data” and “information”). It should be understood that, although these terms (and / or other terms that may be synonymous with each other) may be used synonymously herein, there may be instances where such terms are not intended to be used synonymously. In addition, to the extent prior art knowledge has not been explicitly incorporated by reference herein, it is explicitly incorporated in its entirety. All referenced publications are incorporated herein by reference in their entirety. The techniques and apparatus described in this document include, but are not limited to, the following listed examples: A1. A method, for a user equipment (UE), for reporting a radio link failure (RLF) in a wireless network, wherein the method comprises, after an RLF and a failed connection re-establishment in a first cell associated with a first public land mobile network (PLMN), connecting to a second cell associated with a second PLMN; and sending, to a radio network node (RNN) serving the second cell, an RLF report that includes: a list of PLMN identifiers, including an identifier of the first PLMN; and an indication of whether the second cell is the cell to which the UE was first reconnected. A2. The method according to embodiment A1, wherein the indication comprises an identifier of the second cell, where the second cell is the cell in the 1758931 of 73 that the UE was first reconnected; and no identifier of the cell in which the UE was first reconnected, when the second cell is not the cell in which the UE was first reconnected. A3. The method according to embodiment A1, wherein the indication comprises an identifier of the cell in which the UE was first reconnected; and when the second PLMN is not identified in the list of identifiers of PLMN, an indication that the UE was first reconnected to a different PLMN than the second PLMN. A4. The method according to embodiment A1, wherein the indication comprises, when the second PLMN is identified in the list of PLMN identifiers, an identifier of the cell in which the UE was first reconnected and a first indication of a time until the UE was first reconnected; and when the second PLMN is not identified in the list of PLMN identifiers, an indication that the UE was first reconnected in a PLMN other than the second PLMN. A5. The method according to embodiment A1, wherein the indication comprises a first indication of a time until the UE was first reconnected; and where the second PLMN is not identified in the list of PLMN identifiers, an indication that the UE was first reconnected on a PLMN other than the second PLMN. B1. A method, for a radio network node (RNN) in a wireless network, for receiving radio link failure (RLF) reports from user equipment (UE), wherein the method comprises establishing a connection with a user equipment in a second cell, served by the RNN, which is associated with a second public land mobile network (PLMN); and receiving, from the UE, an RLF report that includes a list of PLMN identifiers, including an identifier of a first PLMN in which the UE experienced RLF and the connection restoration failed; and an indication of whether the second cell is the cell in which the UE was 1758931 of 73 reconnected for the first time. B2. The method according to embodiment B1, wherein the indication comprises an identifier of the second cell, when the second cell is the cell in which the UE was first reconnected; and no identifier of the cell in which the UE was first reconnected, when the second cell is not the cell in which the UE was first reconnected. B3. The method according to embodiment B1, wherein the indication comprises an identifier of the cell in which the UE was first reconnected; and when the second PLMN is not identified in the list of PLMN identifiers, an indication that the UE was first reconnected in a PLMN other than the second PLMN. B4. The method according to embodiment B1, wherein the indication comprises, when the second PLMN is identified in the list of PLMN identifiers, an identifier of the cell in which the UE was first reconnected and a first indication of a time until the UE was first reconnected; and when the second PLMN is not identified in the list of PLMN identifiers, an indication that the UE was first reconnected in a PLMN other than the second PLMN. B5. The method according to embodiment B1, wherein the indication comprises a first indication of a time until the UE was first reconnected; and where the second PLMN is not identified in the list of PLMN identifiers, an indication that the UE was first reconnected to a PLMN other than the second PLMN. B6. The method of any of embodiments B1-B5, further comprising, based on the indication, determining whether the mobility parameters should be adjusted for the cell to which the UE first reconnected. C1. A user equipment (UE) configured to report a radio link failure (RLF) in a wireless network, wherein the UE comprises radio transceiver circuitry configured to communicate with a radio network node (RNN) in the wireless network; and 1758931 of 73 a processing circuit operatively coupled to the radio transceiver circuit, whereby the processing circuit and the radio transceiver circuit are configured to perform operations corresponding to the methods of any of embodiments A1-A5. C2. A user equipment (UE) configured to report a radio link failure (RLF) in a wireless network, wherein the UE is further configured to perform operations corresponding to the methods of any of embodiments A1-A5. C3. A non-transient, computer-readable medium that stores computer-executable instructions that, when executed by the processing circuits of a user equipment (UE) configured to report a radio link failure (RLF) in a wireless network, configure the UE to perform operations corresponding to the methods of any of embodiments A1-A5. C4. A computer program product comprising computer-executable instructions that, when executed by the processing circuits of a user equipment (UE) configured to report a radio link failure (RLF) in a wireless network, configure the UE to perform operations corresponding to the methods of any of embodiments A1-A5. D1. A radio network node (RNN) disposed to receive radio link failure (RLF) reports from user equipment (UE) in a wireless network, the RNN comprising communication interface circuits configured to communicate with one or more UE and with one or more additional RNNs in the wireless network; and processing circuits operatively coupled to the communication interface circuits, whereby the processing circuits and the communication interface circuits are configured to perform operations corresponding to the methods of any of embodiments B1-B6. D2. A radio network node (RNN) arranged to receive radio link failure (RLF) reports from user equipment (UE) in a wireless network, wherein the RNN is further arranged to perform operations corresponding to the methods of any of embodiments B1-B6. D3. A non-transient, computer-readable medium that stores computer-executable instructions which, when executed by the processing circuits of a radio network node (RNN) configured to receive reports from 1758931 of 73 Radio Link Failure (RLF) of User Equipment (UE) in a wireless network, configure the RNN to perform operations corresponding to the methods of any of the embodiment forms B1-B6. D4. A computer program product comprising computer-executable instructions that, when executed by the processing circuitry of a radio network node (RNN) receiving radio link failure (RLF) reports from user equipment (UE) in a wireless network, configures the RNN to perform operations corresponding to the methods of any of embodiments B1-B6.

Claims

1. A method for a user equipment (UE) to report link failures in a wireless network, characterized in that, after a link failure and a failed connection restoration in a first public land mobile network (PLMN), it comprises connecting (1420) to a first cell of the wireless network; and sending (1440) to a radio network node (RNN) in the wireless network a failure report that includes an indication of whether the first cell is associated with the first PLMN, wherein this indication is based on: including an identifier of the first cell in the failure report when the first cell is associated with at least one PLMN identifier associated with the cell where the link failure occurred; or excluding the identifier of the first cell from the failure report when the first cell is not associated with any PLMN identifier associated with the cell where the link failure occurred. 29 Claims follow