WO2025065381A1 - Non-public network out of coverage reporting - Google Patents

Abstract

The present application relates to user equipment (UE) logging and reporting non-public network (NPN) out of coverage (OOC) related information to a network. In an example, upon the UE determining an NPN OOC situation, the UE is configured to log NPN-related information usable to facilitate resoling the NPN OOC situation. Upon being in network coverage, the UE can report the logged NPN-related information using a self-organizing network (SON) reporting procedure and/or a minimization of drive tests (MDT) procedure.

Description

NON-PUBLIC NETWORK OUT OF COVERAGE REPORTING TECHNICAL FIELD

This application relates generally to wireless communication systems, and in particular relates to non-public network out of coverage reporting.

BACKGROUND

Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These standards can include, for example, long term evolution (LTE) (e.g., 4G) , 3GPP new radio (NR) (e.g., 5G) , and other standards.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network environment in accordance with some embodiments.

FIG. 2 illustrates an example of a network in accordance with some embodiments.

FIG. 3 illustrates an example of in-coverage and out of coverage of a user equipment (UE) in accordance with some embodiments.

FIG. 4 illustrates an example of a sequence diagram for a UE reporting a non-public network (NPN) out of coverage (OOC) situation to a network in accordance with some embodiments.

FIG. 5 illustrates an example of an operational flow/algorithmic structure implemented by a UE for reporting NPN OOC to a network in accordance with some embodiments in accordance with some embodiments.

FIG. 6 illustrates an example of an operational flow/algorithmic structure implemented by a network for receiving NPN OOC from a UE in accordance with some embodiments in accordance with some embodiments.

FIG. 7 illustrates an example of receive components in accordance with some embodiments.

FIG. 8 illustrates an example of a UE in accordance with some embodiments.

FIG. 9 illustrates an example of a base station in accordance with some embodiments.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, and techniques in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A/B” and “A or B” mean (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

Embodiments of the present disclosure relate to a user equipment (UE) logging and reporting non-public network (NPN) out of coverage (OOC) related information to a network. In an example, a public land mobile network (PLMN) includes an NPN. Although the UE may be within cell coverage of the NPN, the UE may not find a suitable NPN cell to which the UE can connect due to NPN restrictions. As a result, and depending on a number of factors (e.g., a mode in which the UE can only connect to an NPN) , the UE may be out of coverage (OOC) in the NPN. In such a situation, referred to herein as an NPN OOC situation, the UE can be configured to log NPN-related information while being OOC. This information is usable to reconfigure the NPN such that resolving NPN OOC situations is facilitated. Once the UE is within cell coverage (e.g., in a public network or another NPN) , the UE can be configured to report the logged NPN-related information to the network (e.g., to one or more nodes of the PLMN) . The reporting can follow a self-organizing network (SON) procedure, such as one for reporting a radio link failure (RLF) , a connection establishment failure (CEF) , or a specific NPN report, or a minimization of drive tests (MDT) procedure. Regardless of the type of reporting procedure, the report can implicitly indicate the NPN OOC situation (e.g., by including the NPN-related information) or explicitly indicate this situation (e.g., by including an indicator set to a value corresponding to NPN OOC) . One or many advantages  of reporting the NPN OOC includes enabling the reconfiguration of the NPN such that better coverage can be provided. These and other features are further described herein below.

The following is a glossary of terms that may be used in this disclosure.

The term “circuitry” as used herein refers to, is part of, or includes hardware components that are configured to provide the described functionality. The hardware components may include an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , or a digital signal processor (DSP) . In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, and network interface cards.

The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities that may allow a user to access network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal,  user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.

The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, or workload units. A “hardware resource” may refer to compute, storage, or network resources provided by physical hardware elements. A “virtualized resource” may refer to compute, storage, or network resources provided by virtualization infrastructure to an application, device, or system. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or  any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices for the purpose of transmitting and receiving information.

The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

The term “connected” may mean that two or more elements, at a common communication protocol layer, have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

The term “network element” as used herein refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to or referred to as a networked computer, networking hardware, network equipment, network node, or a virtualized network function.

The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. An information element may include one or more additional information elements.

FIG. 1 illustrates a network environment 100, in accordance with some embodiments. The network environment 100 may include a UE 104 and a gNB 108. The gNB 108 may be a base station that provides a wireless access cell, for example, a Third Generation Partnership Project (3GPP) New Radio (NR) cell, through which the UE 104 may communicate with the gNB 108. The UE 104 and the gNB 108 may communicate over an air interface compatible with 3GPP technical specifications, such as those that define Fifth Generation (5G) NR system standards.

The gNB 108 may transmit information (for example, data and control signaling) in the downlink direction by mapping logical channels on the transport channels, and transport channels onto physical channels. The logical channels may transfer data between a radio link control (RLC) and MAC layers; the transport channels may transfer data between the MAC and PHY layers; and the physical channels may transfer information across the air interface.  The physical channels may include a physical broadcast channel (PBCH) , a physical downlink control channel (PDCCH) , and a physical downlink shared channel (PDSCH) .

The PBCH may be used to broadcast system information that the UE 104 may use for initial access to a serving cell. The PBCH may be transmitted along with physical synchronization signals (PSS) and secondary synchronization signals (SSS) in a synchronization signal (SS) /PBCH block. The SS/PBCH blocks (SSBs) may be used by the UE 104 during a cell search procedure (including cell selection and reselection) and for beam selection.

The PDSCH may be used to transfer end-user application data, signaling radio bearer (SRB) messages, system information messages (other than, for example, MIB) , and paging messages.

The PDCCH may transfer DCI that is used by a scheduler of the gNB 108 to allocate both uplink and downlink resources. The DCI may also be used to provide uplink power control commands, configure a slot format, or indicate that preemption has occurred.

The gNB 108 may also transmit various reference signals to the UE 104. The reference signals may include DMRSs for the PBCH, PDCCH, and PDSCH. The UE 104 may compare a received version of the DMRS with a known DMRS sequence that was transmitted to estimate an impact of the propagation channel. The UE 104 may then apply an inverse of the propagation channel during a demodulation process of a corresponding physical channel transmission. The UE 104 can similarly transmit various reference signal to the gNB 108 including, for instance, DMRSs, for processing by the gNB 108 in association with uplink channels (e.g., a physical uplink control channel (PUCCH) and a physical uplink shared channel (PUSCH) ) .

The reference signals may also include channel status information reference signals (CSI-RS) . The CSI-RS may be a multi-purpose downlink transmission that may be used for CSI reporting, beam management, connected mode mobility, radio link failure detection, beam failure detection and recovery, and fine tuning of time and frequency synchronization.

The reference signals and information from the physical channels may be mapped to resources of a resource grid. There is one resource grid for a given antenna port, subcarrier spacing configuration, and transmission direction (for example, downlink or uplink) . The basic unit of an NR downlink resource grid may be a resource element, which may be defined  by one subcarrier in the frequency domain and one orthogonal frequency division multiplexing (OFDM) symbol in the time domain. Twelve consecutive subcarriers in the frequency domain may compose a physical resource block (PRB) . A resource element group (REG) may include one PRB in the frequency domain and one OFDM symbol in the time domain, for example, twelve resource elements. A control channel element (CCE) may represent a group of resources used to transmit PDCCH. One CCE may be mapped to a number of REGs, for example, six REGs.

The UE 104 may transmit data and control information to the gNB 108 using physical uplink channels. Different types of physical uplink channels are possible including, for instance, a PUCCH and a PUSCH. Whereas the PUCCH carries control information from the UE 104 to the gNB 108, such as uplink control information (UCI) , the PUSCH carries data traffic (e.g., end-user application data) and can carry UCI.

The UE 104 and the gNB 108 may perform beam management operations to identify and maintain desired beams for transmission in the uplink and downlink directions. The beam management may be applied to both PDSCH and PDCCH in the downlink direction, and PUSCH and PUCCH in the uplink direction.

In an example, communications with the gNB 108 and/or the base station can use channels in the frequency range 1 (FR1) band, frequency range 2 (FR2) band, and/or high frequency range (FRH) band. The FR1 band includes a licensed band and an unlicensed band. The NR unlicensed band (NR-U) includes a frequency spectrum that is shared with other types of radio access technologies (RATs) (e.g., LTE-LAA, WiFi, etc. ) . A listen-before-talk (LBT) procedure can be used to avoid or minimize collision between the different RATs in the NR-U, whereby a device should apply a clear channel assessment (CCA) check before using the channel.

Although not illustrated in FIG. 1, the network environment 100 may other network components. For example, the network environment 100 can use various radio access networks (RANs) for communicating between a UE (e.g., the UE 104) and a base station (e.g., the NB 108) of the RAN (which may also sometimes be referred to generally as a RAN node, a network node, or simply a node) . For 5G-NR, 3GPP RANs can be referred to as a Next-Generation Radio Access Network (NG-RAN) .

Each RAN may use one or more radio access technologies (RATs) to perform communication between the base station and the UE. For example, NG-RAN implements NR  RAT (sometimes referred to herein as 5G RAT, 5G NR RAT, or simply NR) . In certain deployments, NG-RAN may also implement long term evolution (LTE) RAT.

A base station (e.g., the gNB 108) used by a RAN may correspond to that RAN. A RAN provides its communication services with external entities through its connection to a core network (CN) . For example, NG-RAN may utilize a 5G Core Network (5GC) . As used herein, a “network” can refer to any or a combination of a base station, a RAN, or a CN.

In the interest of clarity of explanation, various embodiments of the present disclosure are described in the context of the 5G NR. However, the embodiments are not limited as such and can similarly and equivalently apply to other wireless communication systems, such as the 4G LTE/LTE-A, or various wireless communication systems to be developed in future. Equivalents to the architecture, entities, functions, processes and the like as described in the present disclosure may be found in these communication systems. Various embodiments are also described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and/or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component. Examples of a UE may include a mobile device, a personal digital assistant (PDA) , a tablet computer, a laptop computer, a personal computer, an Internet of Things (IoT) device, or a machine type communications (MTC) device, among other examples, which may be implemented in various objects such as appliances, or vehicles, meters, among other examples.

FIG. 2 illustrates an example of a network 200 in accordance with some embodiments. As illustrated, the network 200 includes a PLMN 210 that implements one or more communication technologies including, for instance, 5G communications. The PLMN can include a public network (PN) 220 and a non-public network (NPN) 230. The public network can be accessible to UEs that are subscribed to or registered with the PLMN 210 (e.g., by having a subscription with an operator of the PLMN 210 or with a different operator having a roaming agreement) . In comparison, the NPN 230 can be a private network accessible to UEs subject to particular NPN restrictions. The terms non-public network and private network can be used interchangeably.

In an example, the NPN 230 can be a stand-alone non-public network (SNPN) . The SNPN can be a private network that does not rely on functions provided by the PLMN 210. In this case, the SNPN can be operated by the same operator of the PLMN 210 and can be thought of as a private network completely separated and isolated from the other components of the PLMN 210. Typically, the SNPN can have an identity (SNPN ID) that can be an identifier of the SNPN and that includes a PLMN ID and a network ID (NID) combination. To have access to the SNPN, a UE is configured with the PLMN ID and NID. The PLMN ID may be a private network ID, based on mobile country code (MCC) .

In another example, the NPN 230 can be a public network integrated non-public network (PNI-NPN) . The PNI-NPN can be private network relying on the support of the PLMN 230. In this case, the SNPN can be operated by the same operator of the PLMN 210 and can be thought of as a private network that uses some of the components of the PLMN 210. Typically, the PNI-NPN can have an identity (PNI-NPN ID) that can be an identifier of the NPI-NPN and that includes a PLMN ID and a closed access group (CAG) ID combination. The CAG ID identifies CAG cells. Network selection and reselection is performed based on the PLMN ID. Cell selection and reselection, and access control are performed based on the CAG ID. The CAG represents a concept for preventing UEs, which are not allowed to access an PNI-NPN, from automatically selecting and accessing a cell of this network.

In both examples, the NPN 230 can include a RAN (e.g., the gNB 208) that provides various NPN cells (referred to as CAG cells in the case of PNI-NPN) . In the case of SNPN, call of the SNPN can be an SNPN-only cell: a cell that is only available for normal service for SNPN subscribers. In the case of PNI-NPN, a cell of the PNI-NPN can be a CAG cell, a CAG member cell, or a CAG-only cell. The CAG cell can be a PLMN cell broadcasting at least one CAG identity. A CAG member cell can be for, for a UE, a CAG cell broadcasting the identity of the selected PLMN, registered PLMN or equivalent PLMN, and for that PLMN, a CAG identifier belonging to the Allowed CAG list of the UE for that PLMN. A CAG-only cell can be a CAG cell CAG cell that is only available for normal service for CAG UEs. The NPN 230 can also include a core network (e.g., a 5GC) such as in the case of SNPN and, such as depending on the deployment of an PNI-NPN) .

A UE 250 can connect to the public network 220 or the NPN 230 depending on a number of factors (e.g., cell coverage, subscription, restrictions, etc. ) . The UE 250 is an  example of the UE 104 of Fig. 1. In the illustration of FIG. 2, the UE 250 is connected to the NPN 230 based on being within coverage of an NPN cell. The UE 250 can be operated in different modes. One example mode is SNPN access mode: a mode of operation whereby the UE 250 only accesses SNPNs. Another example mode is PNI-NPN mode: a mode of operation in which the UE 250 is configured with a CAG-only indication and can only camp on CAG cell. The PNI-NPN mode can also be referred to an PNI-NPN access mode or CAG-only mode.

Different network coverage situations can exist and can depend on the UE’s 250 mode and the type of cells. An acceptable cell can be a cell on which the UE 250 may camp to obtain limited service (e.g., originate emergency calls and receive ETWS and CMAS notifications) . A suitable cell can be a cell on which the UE 250 may camp. OOC can occur, for example, due to radio frequency (RF) reasons (e.g., in a radio link failure situation) . However, OOC can also occur in the context of NPNs, even when there are no RF reasons for it. For example, OOC can occur in a situation when the UE 250 cannot find a suitable cell (also referred to “any cell selection state” ) . With NPN, the UE 250 may be in coverage of an otherwise suitable cell which the UE 250 cannot access due to NPN restrictions (e.g., incorrect SNPN ID or CAG ID) . Such OOC situations are referred to herein as NPN OOC situations.

In an NPN OOC situation, an operator of the NPN 230 may mitigate the problem by reconfiguring the network 200 or at least a portion thereof (e.g., the NPN 230, or the RAN of the NPN) . For example, in the case of PNI-NPN, the CAG IDs can be added to additional cells.

Generally, reporting OOC situations can be beneficial. In particular, network coverage improvements can be deployed to resolve such situations. Various mechanisms, including SON-based and MDT-based mechanisms can be used for the reporting. The UE 250 can be configured to log NPN-related information usable to facilitate the NPN OCC situation resolutions and to report such NPN-related information using any one or a combination of the reporting mechanisms. The reporting itself can implicitly or explicitly indicate that the logged NPN-related information is associated with an NPN OCC situation.

FIG. 3 illustrates an example 300 of in-coverage and out of coverage of a user equipment (UE) in accordance with some embodiments. The example 300 illustrates a sequence of stages: an NPN OOC stage 301, a network coverage stage 302, and an NPN  reconfiguration stage 303. This sequence is for illustrative purposes. Other stages or a different order of these stages are possible.

In the NPN stage 301, a UE 350 may be out of coverage in an NPN 310. The UE 350 is an example of the UE 250 of FIG. 2. The NPN 310 is an example of the NPN 230 of FIG. 2. For example, while operating in SNPN access mode or with CAG-only indication, the UE 350 can only camp on the cell which belongs to SNPN or the UE allowed CAG ID. In particular, if operating in SNPN access mode only, the UE 350 can select or reselect cells within the selected/registered SNPN and a cell can only be considered as suitable if the PLMN and NID broadcast by the cell matches the selected/registered SNPN. In comparison, if operating with CAG-only indication, the UE 350 is only allowed to access a 5G system (5GS) via CAG cells.

In both cases, if a suitable cell is not found, the UE 350 would enter any cell selection state (thereby effectively rendering the UE 350 to be out of coverage) . As explained herein above, it would be useful to report the occurrence of such NPN OOC to the network (e.g., the PLMN) , with relevant information and in such a matter so that the network can differentiate this from other types of OC (e.g., RF-related OOC) . A such, the UE 250 stores network information associated with the NPN 310. The network information is usable to reconfigure the NPN such that resolving OOC situations is facilitated (e.g., NPN-related information further described herein below) . This information can be logged 352 in a memory buffer of the UE 350 (e.g., in an access stratum (AS) buffer or an application buffer) . The logging of the network information can start and end or occupy a portion of time between the start and end of the NPN OCC detection of the UE 350. The detection can be when the UE 350 does not find a suitable cell. The start can correspond to entering the any cell selection state. The end can be when the UE 350 finds a suitable cell (which may belong to the NPN 310 or to another network, such as the public network 320) .

In the network coverage stage 302, the UE 350 has found and is connected to a suitable cell such that it is within network coverage. In the illustration of FIG. 3, the suitable cell belongs to the public network 320. However, the embodiments of the present invention are not limited as such. For example, the suitable cell can belong to the NPN 310, or the UE 350 can gain network coverage via an acceptable cell.

As such, during the network coverage stage 302, the UE 350 can report 354 the logged NPN information. The report can use SON-based reporting mechanism and/or MDT- based reporting. A SON-based report can be any or a combination of an RLF report, a CEF report, or an NPN-specific report. The used report (SON or MDT) need not indicate that it is sent for NPN OCC reasons. Nonetheless, an explicit indication thereof can be added to the report.

The NPN reconfiguration stage 303 can occur after the logged NPN information has been reported while the UE 250 is in coverage or is experiencing again an NPN OOC situation. In the NPN reconfiguration stage 303, the NPN 310 can be updated 360 to resolve (or attempt to resolve) the NPN OOC situation. For example, one or more nodes of the NPN 310 can receive a configuration update 312 corresponding to the resolution. To illustrate, say that the UE 350 reported its configured CAG ID. The configuration update 312 can include the CAG ID as part of instructions to add this CAG ID to a list of CAG IDs allowed by the NPN 310.

FIG. 4 illustrates an example of a sequence diagram 400 for a UE 410 reporting an NPN OOC situation to a network 420 in accordance with some embodiments. The network 420 can be a PLMN that includes an NPN. As illustrated, the UE 410 can determine that it is in OOC situation, particularly an NPN OCC situation. This determination corresponds to the UE 410 not finding a suitable cell and entering an any cell selection state while operating in an SNPN access mode or a PNI-NPN mode. Next, the UE logs NPN-related information. The NPN-related information can include, for example, any or a combination of an indication of whether the NPN is an SNPN or PNI-NPN, an indication of the mode of the UE (e.g., the SNPN access mode or the PNI-NPN mode) , CAG identifiers allowed by the NPN, an identifier of a cell where the OCC error occurred, an identifier of a CAG of the cell, a network identifier of the cell, and identifier of a CAG that the UE is configured to use, or a previous cell ID (e.g., including a CAG ID and/or a NID; this ID can be for a previous cell, which may be the last cell to which the UE 410 was connected prior to the OCC occurrence) .

The UE 410 then becomes in network coverage (e.g., by finding and selecting, reselecting a cell, or establishing a connection to a cell) . The UE 410 can then follow a reporting procedure to report the logged NPN information to the network 420. For example, the logged NPN information can be sent in one or more information elements (IEs) (each can be referred to as an NPN SON report information element) to a base station of the network 420. The reporting procedure can be an RLF reporting procedure, a CEF reporting procedure,  an NPN SON reporting procedure, and/or an MDT reporting procedure. These procedures and the content of the related reports are described herein next.

An RLF reporting procedure can be used to report the logged NPN-related information. According to this procedure, the UE 410 starts a timer (referred to as Τ311 in 5G) upon initiating an RRC connection re-establishment procedure. The timer is stopped upon selection of a suitable NR cell (which is not the case in the NPN OOC situation) . Upon the timer expiring, the UE 410 sets a field in the report to a value (e.g., a no suitable cell found field set to a true value, such as the noSuitableCellFound field in the VarRLF-Report to true) if the procedure was initiated due to radio link failure or handover failure. Then the UE 410 sets an OCC report availability indication in an information element to indicate that logged information is available (e.g., the UE 410 sets rlf-InfoAvailable in UE-MeasurementsAvailable in, for instance, RRCReestablishmentComplete) . The network 420 may fetch the RLF report by sending a request (e.g., by indicating rlf-ReportReq in UEInformationRequest) . The UE can respond to the request with the logged information (e.g., this information is reported in UEInformationResponse) .

In this RLF reporting procedure, the UE 410 operating in the SNPN access mode or with the CAG-only indication can set the noSuitableCellFound in the VarRLF-Report not only in case of RLF (and similarly, CEF) , but also at any time when no suitable private cell is found. In one example, the logged NPN-related information is included in the VarRLF-Report without any indication that the VarLF-Report is sent to report NPN OOC. In this case, when the network 420 receives rlf-InfoAvailable from the UE 410, the network 420 may not know the reporting is because of a private network out of coverage situation and may not be able to distinguish from an RLF OCC situation. Then the network 420 may not fetch the report even though it would have been interested in it. If fetched, the network 420 may become aware of the NPN OCC situation because of the report NPN-related information. In other words, the presence of NPN-related information in RLF-Report may indicate this is “NPN OOC” case. Nonetheless, because the network 420 may lack awareness prior to fetching, when fetching actually occurs, the network 420 may think it is a regular RLF report and may expect some information which may not be available.

Enhancements can be made to provide such awareness. For example, a new availability indication can be defined to indicate that the report (e.g., the VarRLF-Report) is sent for NPN OCC reasons. This indication ca be referred to herein as an OOC indication.  The OOC indication can be NPN information available indication in a UE-MeasurementsAvailable information element (e.g., npn-InfoAvailable in UE-MeasurementsAvailable) . In another example, a new (e.g., Boolean) indicator is defined in the report (e.g., included in UEInformationResponse-r16) to indicate this is a private network out of coverage report. This new indication can also be referred to as an OOC indication. In this example, the OOC indication can include a no suitable cell found field (e.g., noSuitableCellFound field) set to a true value in the NPN SON report. The no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.

Regardless of the OOC indication (e.g., whether explicit by being an npn-InfoAvailable or a Boolean indicator, or implicit by being the NPN-related information itself) , various types of NPN-related information may be logged when the timer expires and can be added to the report (referred to herein as the NPN SON report) . This information can include any or a combination of an indication of the NPN Mode (SNPN or PNI-NPN) , whether the UE 410 is in an SNPN access mode only, the allowed CAG IDs, the cell ID of the cell where the error occurred, a CAG ID of the cell where the error occurred, and/or the NID of the cell where the error occurred.

A CEF reporting procedure can be used to report the logged NPN-related information. the UE 410 starts a timer (referred to as Τ300 in 5G) upon initiating an RRC connection establishment procedure. The timer is stopped upon reception of RRCSetup or RRCReject or cell reselection (which is not the case in the NPN OOC situation) . Upon the timer expiring, the UE 410 logs CEF-related information. Then the UE sets connEstFailInfoAvailable (in UE-MeasurementsAvailable, for instance, in RRCReestablishmentComplete) . The network 420 network may fetch the CEF report by indicating ConnEstFailReportReq (e.g., in UEInformationRequest) . The UE 410 then sends the CEF report in UEInformationResponse.

In this CEF reporting procedure, when operating in SNPN access mode or with CAG-only indication, the UE 410 would only attempt RRC connection establishment in a cell that supports the UE’s 410 NPN. Therefore, the case when such a UE 410 needs to establish an RRC connection but cannot because the UE 410 is out of coverage of that NPN can be indicated in the CEF report. In particular, when upper layers request the UE 410 when it is out of coverage, this event would be logged (e.g., in VarConnEstFailReport) and then reported using the usual CEF reporting procedure. The CEF report can include the same  NPN-related information described herein above. Likewise, an explicit or an implicit OOC indication can be used. When the CEF report includes NPN-related information, this report can be referred to herein also as an NPN SON report.

An NPN-specific reporting procedure can be defined for specific NPN SON reporting (e.g., separate and different from RLF or CEF reporting) . Here, the NPN SON report can be a new internal variable that is defined in a technical specification (and can be referred to as VarNPN-Report, similar to labeling a VarRLF-Report for RLF reporting) .

When the UE 410 is operating in SNPN access mode or with CAG-only indication, the UE 410 can a no suitable cell found field set to a true value, such as a noSuitableCellFound field to a true value in the VarNPN-Report. The UE 410 can also store NPN-related information, which can be included in the VARNPN-Report, including any or a combination of: an indication of the NPN Mode (SNPN or PNI-NPN) , an indication of whether the UE 410 is operating in an SNPN access mode only, allowed CAG IDs, a CAG ID of the cell where the error occurred, a NID of the cell where the error occurred, a previous cell id (including a CAG ID and/or a NID) . A new availability indication (referred to herein as OOC indication) such, as npn-InfoAvailable, can be defined and can be included in UE-MeasurementsAvailable IE. The UE 410 sets this information availability to true when the UE 410 has logged information on NPN OOC. A new request (e.g., npn-ReportReq) can be defined and can be included in UEInformationRequest. If the network 420 sets npn-ReportReq to true, the UE 410 includes the logged NPN-related information in UEInformationResponse. A new information element (e.g., npn-Report) can also defined and can be included in UEInformationResponse (this information element can carry all the information from VarNPN-Report) .

An MDT reporting procedure can be used to report the logged NPN-related information. According to this procedure, the UE 410 receives a configuration for MDT logging while the UE is in an RRC_CONNECTED state. The UE 410 then starts a timer (referred to as T330 in 5G) . While in an RRC_IDLE state or an RRC_INACTIVE state, the 410 can log MDT information. The UE 410 can report the logged MDT information to the network 420 when it re-enters to the RRC_CONNECTED state.

If the UE 410 is in an NPN OCC situation (e.g., upon detection that the UE 410 is in any cell selection state) , the UE 410 can set anyCellSelectionDetected in LogMeasInfo to indicate the detection of no suitable or no acceptable cell found. Then the UE 410 provides  the information in LogMeasReport included in UEInformationResponse. As such, the network 420 can detect that the UE 420 is an NPN OCC situation. The MDT report (e.g., the LogMeasReport) can include NPN-related information. This information can be the same as above and/or include any or a combination of an indication when no suitable cell is found but an acceptable cell is found, an indication of the NPN Mode (SNPN or PNI-NPN) , a CAG ID, and/or a NID.

When NPN-related information is reported, it may be relevant that the NPN-related information is sent to an authorized entity. As such, the UE 410 can be configured to check whether it can report the logged information before sending such information.

Typically, the UE 410 would only provide SON availability indication to the same network (the same PLMN) as where SON was configured (otherwise it may result in information leakage from one operator to another) . The same logic applies to reporting the OOC indication and/or the NPN information in the case of NPN OOC. In this case, the network is identified not just by PLMN, but rather by a PLMN ID with a CAG ID or NID.

There may be an exception to this, in case of PNI-NPN. Particular, unlike SNPN, in PNI-NPN both private and non-private networks are operated by the same entity. Therefore, the issue of information leakage may not apply for CAG. In which case, the restriction may be relaxed and SON reports in case of PNI-NPN may not need to check that the report is sent to the same CAG as the one where SON was configured. Nevertheless, CAG information can still be provided in the report.

As such, the NPN-related information can be considered as SON information that is to be sent in a SON report. This SON report is at least one of a RLF, or a CEF report, or an NPN-specific report. When the UE 410 is operated in an SNPN access mode, the UE 410 can determine whether the NPN belongs to the same PLMN where SON reporting was configured for the UE 410. The NPN-related information can be sent upon determining that the NPN belongs to the same PLMN where SON reporting was configured for the UE 410. Otherwise, the NPB-related information is not sent. In comparison, when the UE 410 is operating in the PNI-NPN mode, the UE 410 can send the NPN-related information while forgoing a determination of whether the NPN belongs to the same PLMN where SON reporting was configured for the UE 410 (e.g., without performing such a check) .

In an example, the operational flow/algorithmic structure 500 includes, at step 512, determining, while the UE is operating in a mode and is within radio frequency (RF)  coverage of a cell of a public land mobile network (PLMN) , that the UE is out of coverage (OOC) in a non-public network (NPN) that is associated with the PLMN, the mode being at least one of a stand-alone non-public network (SNPN) access mode or a public network integrated non-public network (PNI-NPN) mode . For example, the NPN is an SPSN or a PNI-NPN. The UE can determine that no cell is found and enter any cell selection state.

In an example, the operational flow/algorithmic structure 500 includes, at step 514, storing an OOC indication that the UE is OOC in the NPN. The OCC indication can be an explicit indication, such as any or a combination of an availability indication or Boolean indicator (e.g., Boolean indicator) defined in a report to indicate this is a private network out of coverage report. The OCC indication can be stored any time after the any cell selection state is entered up to when the UE is in network coverage again. For instance, the OCC indication is logged after a timer (e.g., T311, T300, or T330) expires. The OCC indication can alternatively be an implicit indication corresponding to the report including network information.

In an example, the operational flow/algorithmic structure 500 includes, at step 516, storing network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated. For instance, the network information includes NPN-related information described herein above.

In an example, the operational flow/algorithmic structure 500 includes, at step 518, sending, to the PLMN, the OOC indication and the network information. For instance, upon the UE being in network coverage again, the UE can send a report (an RLF report, a CEF report, an NPN-specific report, and/or an MDT report) that includes the logged NPN-indication and explicitly or implicitly the OOC indication.

FIG. 6 illustrates an example of an operational flow/algorithmic structure 600 implemented by a network for receiving NPN OOC from a UE in accordance with some embodiments in accordance with some embodiments. The operational flow/algorithmic structure 600 can be implemented by one or more nodes of the network including a base station, a RAN, and/or a core network.

In an example, the operational flow/algorithmic structure 600 includes, at step 612, receiving, from a user equipment (UE) , a message indicating that stored information is available from the UE. For instance, this message is an RRC message that information is available for the network to request from the UE as described herein above.

In an example, the operational flow/algorithmic structure 600 includes, at step 614, requesting the UE to send at least a portion of the stored information. For instance, this request is sent in an RRC message as described herein above.

In an example, the operational flow/algorithmic structure 600 includes, at step 616, receiving, from the UE, an OOC indication that, prior to the message, the UE was OOC in an NPN that is associated with a PLMN. For instance, the OCC indication can be received in an RRC message in response to the request from the network, where this message can comprise a report that includes the OOC indication.

In an example, the operational flow/algorithmic structure 600 includes, at step 618, receiving, from the UE, network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated, wherein the stored information includes the OOC indication and the network information. For instance, the network information is NPN-related information that can be received in the RRC message in response to the request from the network, where the report included in this message can also comprise a NPN-related information.

FIG. 7 illustrates receive components 700, in accordance with some embodiments. A UE, such as any of the above described UEs, can include the receive components 700. The receive components 700 may include an antenna panel 704 that includes a number of antenna elements. The panel 704 is shown with four antenna elements, but other embodiments may include other numbers.

The antenna panel 704 may be coupled to analog beamforming (BF) components that include a number of phase shifters 708 (1) –708 (4) . The phase shifters 708 (1) –708 (4) may be coupled with a radio-frequency (RF) chain 712. The RF chain 712 may amplify a receive analog RF signal, downconvert the RF signal to baseband, and convert the analog baseband signal to a digital baseband signal that may be provided to a baseband processor for further processing.

In various embodiments, control circuitry, which may reside in a baseband processor, may provide BF weights (for example W1 –W4) , which may represent phase shift values, to the phase shifters 708 (1) –708 (4) to provide a receive beam at the antenna panel 704. These BF weights may be determined based on the channel-based beamforming.

FIG. 8 illustrates a UE 800, in accordance with some embodiments. The UE 800 may be similar to and substantially interchangeable with any of the UEs described herein above. A device, such as one described in any of the above figures, can include similar components, including for instance, processors, memory, and RF interface circuitry.

Similar to that described above with respect to the UE 104, the UE 800 may be any mobile or non-mobile computing device, such as mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage/current meters, actuators, etc. ) , video surveillance/monitoring devices (for example, cameras, video cameras, etc. ) , wearable devices, or relaxed-IoT devices. In some embodiments, the UE may be a reduced capacity UE or NR-Light UE.

The UE 800 may include processors 804, RF interface circuitry 808, memory/storage 812, user interface 816, sensors 820, driver circuitry 822, power management integrated circuit (PMIC) 824, and battery 828. The components of the UE 800 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the UE 800. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

The components of the UE 800 may be coupled with various other components over one or more interconnects 832, which may represent any type of interface, input/output, bus (local, system, or expansion) , transmission line, trace, optical connection, etc., that allows various circuit components (on common or different chips or chipsets) to interact with one another.

The processors 804 may include processor circuitry, such as baseband processor circuitry (BB) 804A, central processor unit circuitry (CPU) 804B, and graphics processor unit circuitry (GPU) 804C. The processors 804 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storage 812 to cause the UE 800 to perform operations as described herein.

In some embodiments, the baseband processor circuitry 804A may access a communication protocol stack 836 in the memory/storage 812 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 804A may access the communication protocol stack to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum “NAS” layer. In some embodiments, the PHY layer operations may additionally/alternatively be performed by the components of the RF interface circuitry 808.

The baseband processor circuitry 804A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

The baseband processor circuitry 804A may also access group information from memory/storage 812 to determine search space groups in which a number of repetitions of a PDCCH may be transmitted.

The memory/storage 812 may include any type of volatile or non-volatile memory that may be distributed throughout the UE 800. In some embodiments, some of the memory/storage 812 may be located on the processors 804 themselves (for example, L1 and L2 cache) , while other memory/storage 812 is external to the processors 804 but accessible thereto via a memory interface. The memory/storage 812 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random-access memory (DRAM) , static random-access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

The RF interface circuitry 808 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 800 to communicate with other devices over a radio access network. The RF interface circuitry 808 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

In the receive path, the RFEM may receive a radiated signal from an air interface via an antenna 850 and proceed to filter and amplify (with a low-noise amplifier) the signal.  The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 804.

In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna 850.

In various embodiments, the RF interface circuitry 808 may be configured to transmit/receive signals in a manner compatible with NR access technologies.

The antenna 850 may include a number of antenna elements that each convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna 850 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna 850 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna 850 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

The user interface circuitry 816 includes various input/output (I/O) devices designed to enable user interaction with the UE 800. The user interface 816 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input, including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs/indicators (for example, binary status indicators, such as light emitting diodes (LEDs) and multi-character visual outputs) , or more complex outputs, such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, projectors, etc. ) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 800.

The sensors 820 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units comprising accelerometers; gyroscopes; or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers; 3-axis gyroscopes; or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example; cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

The driver circuitry 822 may include software and hardware elements that operate to control particular devices that are embedded in the UE 800, attached to the UE 800, or otherwise communicatively coupled with the UE 800. The driver circuitry 822 may include individual drivers allowing other components to interact with or control various input/output (I/O) devices that may be present within, or connected to, the UE 800. For example, driver circuitry 822 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensor circuitry 820 and control and allow access to sensor circuitry 820, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

The PMIC 824 may manage power provided to various components of the UE 800. In particular, with respect to the processors 804, the PMIC 824 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

In some embodiments, the PMIC 824 may control, or otherwise be part of, various power saving mechanisms of the UE 800. For example, if the platform UE is in an RRC_Connected state (described herein above as RRC_CONNECTED state) , where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the UE 800 may power down for brief intervals of time and thus save power. If there is  no data traffic activity for an extended period of time, then the UE 800 may transition off to an RRC_Idle state (described herein above as RRC_IDLE state) , where it disconnects from the network and does not perform operations, such as channel quality feedback, handover, etc. The UE 800 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The UE 800 may not receive data in this state; in order to receive data, it must transition back to RRC_Connected state. An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours) . During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

Battery 828 may power the UE 800, although in some examples the UE 800 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 828 may be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 828 may be a typical lead-acid automotive battery.

FIG. 9 illustrates a gNB 900, in accordance with some embodiments. The gNB 900 may be similar to and substantially interchangeable with the gNB 108 of FIG. 1 and is an example of any of the base stations described herein above.

The gNB 900 may include processors 904, RAN interface circuitry 908, core network (CN) interface circuitry 912, and memory/storage circuitry 916. The components of the gNB 900 may be coupled with various other components over one or more interconnects 928.

The processors 904, RAN interface circuitry 908, memory/storage circuitry 916 (including communication protocol stack 910) , antenna 950, and interconnects 928 may be similar to like-named elements shown and described with respect to FIG. 8.

The CN interface circuitry 912 may provide connectivity to a core network, for example, a Fifth Generation Core network (5GC) using a 5GC-compatible network interface protocol, such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to/from the gNB 900 via a fiber optic or wireless backhaul. The CN interface circuitry 912 may include one or more dedicated processors or FPGAs to  communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 912 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

Examples

In the following sections, further exemplary embodiments are provided.

Example 1 includes a method implemented by a user equipment (UE) , the method comprising: determining, while the UE is operating in a mode and is within radio frequency (RF) coverage of a cell of a public land mobile network (PLMN) , that the UE is out of coverage (OOC) in a non-public network (NPN) that is associated with the PLMN, the mode being at least one of a stand-alone non-public network (SNPN) access mode or a public network integrated non-public network (PNI-NPN) mode; storing an OOC indication that the UE is OOC in the NPN; and storing network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated.

Example 2 includes a computer-implemented method comprising: receiving, from a user equipment (UE) , a message indicating that stored information is available from the UE;  requesting the UE to send at least a portion of the stored information; receiving, from the UE, an out of coverage (OOC) indication that, prior to the message, the UE was OOC in a non-public network (NPN) that is associated with a public land mobile network (PLMN) while being within radio frequency (RF) coverage of a cell of the PLMN; and receiving, from the UE, network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated, wherein the stored information includes the OOC indication and the network information.

Example 3 includes the method of any example 1-2, further comprising UE to sending, to the PLMN, the OOC indication and the network information in at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or a minimization of drive tests (MDT) report.

Example 4 includes the method of any example 1-3, wherein the OOC indication includes a no suitable cell found field set to a true value in a radio link failure (RLF) report or a connection establishment failure (CEF) report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.

Example 5 includes the method of any example 1-4, wherein the execution of the instructions further configures the UE to set an OOC report availability indication to a true value in a UE-MeasurementsAvailable information element.

Example 6 includes the method of any example 1-5, wherein the OOC indication is included in a self-organizing network (SON) report and indicates that the SON report is a private network out of coverage report.

Example 7 includes the method of any example 1-6, wherein the OOC indication includes a no suitable cell found field set to a true value in a NPN self-organizing network (SON) report, wherein the no suitable cell field is set to the true value upon the UE determining that the UE is OOC in the NPN.

Example 8 includes the method of example 7, further comprising: setting the OOC indication as an NPN information available indication having a true value in a UE-MeasurementsAvailable information element; receiving a radio resource control (RRC) UEInformationRequest message requesting the NPN SON report; including the network information in an NPN SON report information element; and sending the NPN SON report information element in a RRC UEInformationResponse message.

Example 9 includes the method of any example 1-8, wherein the network information includes at least one of: an indication of whether the NPN is an SNPN or a PNI-NPN, an indication of the mode of the UE, closed access group (CAG) identifiers allowed by the NPN, an identifier of a cell where an OOC error occurred, an identifier of a CAG of the cell, or a network identifier of the cell.

Example 10 includes the method of any example 1-9, wherein the network information is sent in a minimization of drive tests (MDT) report.

Example 11 includes the method of example 10, wherein the network information includes at least one of: an indication that no suitable cell is found but an acceptable cell is found, an indication of whether the NPN is an SNPN or a PNI-NPN, a closed access group (CAG) identifier, or a network identifier of a cell.

Example 12 includes the method of any example 1-11, wherein the operations further comprise sending the network information in a self-organizing network (SON) report, wherein the SON report is at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or an NPN-specific report.

Example 13 includes the method of example 12, wherein the mode is the SNPN access mode, and further comprising: determining whether the NPN belongs to the same PLMN where SON reporting was configured for the UE, wherein the network information is sent upon determining that the NPN belongs to the same PLMN where SON reporting was configured for the UE.

Example 14 includes the method of example 12, wherein the mode is the PNI-NPN mode, and wherein the network information is sent while forgoing a determination of whether the NPN belongs to the same PLMN where SON reporting was configured for the UE.

Example 15 includes the method of any example 1-14, wherein the OOC indication and the network information are sent in at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or a minimization of drive tests (MDT) report.

Example 16 includes the method of any example 1-15, wherein the OOC indication includes a no suitable cell found field set to a true value in a radio link failure (RLF) report or a connection establishment failure (CEF) report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.

Example 17 includes the method of any example 1-16, wherein the OOC indication includes a no suitable cell found field set to a true value in a NPN report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.

Example 18 includes the method of any example 1-17, wherein the network information includes at least one of: an indication of whether the NPN is an SNPN or a PNI-NPN, an indication of a mode of the UE, closed access group (CAG) identifiers allowed by the NPN, an identifier of a cell where an OOC error occurred, an identifier of a CAG of the cell, or a network identifier of the cell.

Example 19 includes the method of any example 1-18, further comprising: receiving, from the UE, an OOC report availability indication set to a true value in a UE-MeasurementsAvailable information element.

Example 20 includes an apparatus, such as a UE, comprising means to perform one or more elements of a method described in or related to any of examples 1, 3-19, or any other method or process described herein.

Example 21 includes one or more non-transitory computer-readable media comprising instructions to cause an electronic device, such as a UE, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1, 3-19, or any other method or process described herein.

Example 22 includes an apparatus, such as a UE, comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1, 3-19, or any other method or process described herein.

Example 23 includes a method, technique, or process as described in or related to any of examples 1, 3-19, or portions or parts thereof.

Example 24 includes an apparatus, such as a UE, comprising: one or more processors and one or more memory (e.g., one or more computer-readable media) comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1, 3-19, or portions thereof.

Example 25 includes a signal as described in or related to any of examples 1, 3-19, or portions or parts thereof.

Example 26 includes a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1, 3-19, or portions or parts thereof, or otherwise described in the present disclosure.

Example 27 includes a signal encoded with data as described in or related to any of examples 1, 3-19, or portions or parts thereof, or otherwise described in the present disclosure.

Example 28 includes a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1, 3-19, or portions or parts thereof, or otherwise described in the present disclosure.

Example 29 includes an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1, 3-19, or portions thereof.

Example 30 includes a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1, 3-19, or portions thereof.

Example 31 includes a network comprising means to perform one or more elements of a method described in or related to any of examples 2-19, or any other method or process described herein.

Example 32 includes one or more non-transitory computer-readable media comprising instructions to cause a network upon execution of the instructions by one or more processors of the network, to perform one or more elements of a method described in or related to any of examples 2-19, or any other method or process described herein.

Example 33 includes a network comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 2-19, or any other method or process described herein.

Example 34 includes a network comprising: one or more processors and one or more memory (e.g., one or more computer-readable media) comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 2-19, or portions thereof.

Any of the above-described examples may be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims (20)

1. A user equipment (UE) comprising:

   one or more processors; and

   one or more memory storing instructions that, upon execution by the one or more processors, configure the UE to:

   determine, while the UE is operating in a mode and is within radio frequency (RF) coverage of a cell of a public land mobile network (PLMN) , that the UE is out of coverage (OOC) in a non-public network (NPN) that is associated with the PLMN, the mode being at least one of a stand-alone non-public network (SNPN) access mode or a public network integrated non-public network (PNI-NPN) mode;

   store an OOC indication that the UE is OOC in the NPN; and

   store network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated.
2. The UE of claim 1, wherein the execution of the instructions further configures the UE to send, to the PLMN, the OOC indication and the network information in at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or a minimization of drive tests (MDT) report.
3. The UE of claim 1, wherein the OOC indication includes a no suitable cell found field set to a true value in a radio link failure (RLF) report or a connection establishment failure (CEF) report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.
4. The UE of claim 1, wherein the execution of the instructions further configures the UE to set an OOC report availability indication to a true value in a UE-MeasurementsAvailable information element.
5. The UE of claim 1, wherein the OOC indication is included in a self-organizing network (SON) report and indicates that the SON report is a private network out of coverage report.
6. The UE of claim 1, wherein the OOC indication includes a no suitable cell found field set to a true value in a NPN self-organizing network (SON) report, wherein the no suitable cell field is set to the true value upon the UE determining that the UE is OOC in the NPN.
7. The UE of claim 6, wherein the execution of the instructions further configures the UE to:

   set the OOC indication as an NPN information available indication having a true value in a UE-MeasurementsAvailable information element;

   receive a radio resource control (RRC) UEInformationRequest message requesting the NPN SON report;

   include the network information in an NPN SON report information element; and

   send the NPN SON report information element in a RRC UEInformationResponse message.
8. The UE of claim 1, wherein the network information includes at least one of: an indication of whether the NPN is an SNPN or a PNI-NPN, an indication of the mode of the UE, closed access group (CAG) identifiers allowed by the NPN, an identifier of a cell where an OOC error occurred, an identifier of a CAG of the cell, or a network identifier of the cell.
9. One or more computer-readable storage media storing instructions that, upon execution on a user equipment (UE) , cause the UE to perform operations comprising:

   determining, while the UE is operating in a mode and is within radio frequency (RF) coverage of a cell of a public land mobile network (PLMN) , that the UE is out of coverage (OOC) in a non-public network (NPN) that is associated with the PLMN, the mode being at least one of a stand-alone non-public network (SNPN) access mode or a public network integrated non-public network (PNI-NPN) mode;

   storing an OOC indication that the UE is OOC in the NPN; and

   storing network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated.
10. The one or more computer-readable storage media of claim 9, wherein the network information is sent in a minimization of drive tests (MDT) report.
11. The one or more computer-readable storage media of claim 10, wherein the network information includes at least one of: an indication that no suitable cell is found but an  acceptable cell is found, an indication of whether the NPN is an SNPN or a PNI-NPN, a closed access group (CAG) identifier, or a network identifier of a cell.
12. The one or more computer-readable storage media of claim 9, wherein the operations further comprise sending the network information in a self-organizing network (SON) report, wherein the SON report is at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or an NPN-specific report.
13. The one or more computer-readable storage media of claim 12, wherein the mode is the SNPN access mode, and wherein the operations further comprise:

    determining whether the NPN belongs to the same PLMN where SON reporting was configured for the UE, wherein the network information is sent upon determining that the NPN belongs to the same PLMN where SON reporting was configured for the UE.
14. The one or more computer-readable storage media of claim 12, wherein the mode is the PNI-NPN mode, and wherein the network information is sent while forgoing a determination of whether the NPN belongs to the same PLMN where SON reporting was configured for the UE.
15. A computer-implemented method comprising:

    receiving, from a user equipment (UE) , a message indicating that stored information is available from the UE;

    requesting the UE to send at least a portion of the stored information;

    receiving, from the UE, an out of coverage (OOC) indication that, prior to the message, the UE was OOC in a non-public network (NPN) that is associated with a public land mobile network (PLMN) while being within radio frequency (RF) coverage of a cell of the PLMN; and

    receiving, from the UE, network information associated with the NPN, the network information usable to reconfigure the NPN such that resolving OOC situations is facilitated, wherein the stored information includes the OOC indication and the network information.
16. The computer-implemented method of claim 15, wherein the OOC indication and the network information are sent in at least one of a radio link failure (RLF) report, a connection establishment failure (CEF) report, or a minimization of drive tests (MDT) report.
17. The computer-implemented method of claim 15, wherein the OOC indication includes a no suitable cell found field set to a true value in a radio link failure (RLF) report or a connection establishment failure (CEF) report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.
18. The computer-implemented method of claim 15, wherein the OOC indication includes a no suitable cell found field set to a true value in a NPN SON report, wherein the no suitable cell found field is set to the true value upon the UE determining that the UE is OOC in the NPN.
19. The computer-implemented method of claim 15, wherein the network information includes at least one of: an indication of whether the NPN is an SNPN or a PNI-NPN, an indication of a mode of the UE, closed access group (CAG) identifiers allowed by the NPN, an identifier of a cell where an OOC error occurred, an identifier of a CAG of the cell, or a network identifier of the cell.
20. The computer-implemented method of claim 15, further comprising:

    receiving, from the UE, an OOC report availability indication set to a true value in a UE-MeasurementsAvailable information element.