Patent Description:
<CIT> discloses a network coverage hole detection mechanism for detecting a hole in LTE cell coverage, that uses a UE to perform MDT Minimisation of Drive Test data collection. The data may be collected and stored when the UE is in idle mode and it may be reported when the UE reconnects to the network, in some cases in response to a request for the data. In other embodiments, the data may be collected in a connected state and reported immediately. The UE may be triggered to record MDT data in response to a cell re-selection event, that is moving between cells or detecting a cell coverage hole.

<NUM> targets a variety of use cases and industries. A more distributed core with a combination of a variety of RAN deployments is generally viewed as the framework for more flexibility, customization, and service-driven management in a viable <NUM> system. From a network traffic management perspective, <NUM> also allows coordination and arrangements to different services to enhance mobile network performance.

A primary <NUM> data-driven use case, Enhanced Mobile Broadband (eMBB), requires high data rates across a wide radio coverage area when a user communicates over the air with a base station in regular radio operation in good radio coverage. However, the radio coverage can coexist with supportive deployments.

For example, an eMBB user, capable of cellular and Wi-Fi or Bluetooth communication, moving inside a WLAN network, upon detecting the presence of the WLAN, may switch to IP mode in order to access the WLAN and may automatically connect to it. This allows the eMBB user to get seamless voice and data session continuity, for example, by switching a call to a VoIP (Voice over IP) call.

Another example is Vehicle-to-Everything (V2X) Communications, which are based on D2D communications, defined as part of ProSe (Proximity Services). As part of ProSe services, a new D2D interface, designated as PC5, also known as sidelink at the physical layer, was introduced and, as part of V2V (vehicle-to-vehicle), it has been enhanced for vehicular use cases, specifically addressing high speed and high density of the network nodes. Vehicle-to-everything communications technology allows vehicles to directly communicate with each other, with roadside infrastructure, and with other road users to deliver traffic efficiency and road safety, even in environments where radio coverage is not available.

In yet another example, non-terrestrial networks (NTN) refers to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission. These non-terrestrial networks will provide satellite infrastructure support for <NUM>, and will be used to foster the <NUM> service roll-out in unserved or underserved areas to upgrade the performance of terrestrial networks.

Self-Organising Networks (SON), which encompass solutions for network self-configuration and self-optimisation, were introduced in LTE to support deployment of system and performance optimization. SON became a baseline for the <NUM> standardized method for data collection. MDT has been used as a parallel and complementary feature to enable UE feedback which will further allow network optimization based on end-user reports. The key objective of SON- and MDT-oriented solutions was to introduce automated data collection in <NUM> by gathering feedback from the field from regular end-users. Two types of MDT, Immediate and Logged MDT, provide methods to deliver real-time measurements, that is, results of measurements performed for typical RRM operations, and non-real time measurement results taken during a time when the UE was out of network reach, such as by being in RRC IDLE or RRC INACTIVE states, respectively. While the data contents are expected to be differentiated to provide reliable feedback on different services and a better reflection of diverse <NUM> requirements, the MDT reports are also used to record UE feedback when having a 3GPP/RRC connection released does not cover the possibility of investigating user behavior and experience in networks coexisting as supportive deployments for regular radio.

However, different types of UEs may have different connectivity to different networks and for different services. As MDT data collection focuses on radio measurements, users, providing logged data collection from the same network area, will not reflect their real network perception. A regular eMBB user may lose network coverage and experience an actual "out of radio coverage" state, and will record the state as "out of service" detection, while an underlying network, deployed at the coverage hole or at the edge of eMBB network, may provide a service, and the user may be able to establish direct communication through a supportive interface. For instance, if the underlying network is a WLAN, the user can establish a Wi-Fi connection through a supportive interface while, if the underlying network is a V2X, the user may be able to establish direct communication through a PC5 link. Thus, even if a user may be in "out of radio coverage", in these cases it can still enjoy a service. In future deployments, such as cell-less, there will be no means to know real coverage/service holes, that is, where there is really a connectivity interruption. For network providers, who can jointly serve the different infrastructures, the problem lies in the interpretation of whether radio/cell loss is equivalent to absolute dis-connectivity.

The present disclosure introduces a new "Out of Any Connectivity" state to allow the UE to monitor the state and to enter it once there is a loss of any alternate (network) connection.

In a first aspect of the present disclosure, a method according to claim <NUM> is provided.

The method may further comprise: monitoring <NUM>-network coverage; detecting a loss of <NUM>-network coverage; and beginning to store "Out of <NUM> Radio Coverage" information.

The logged measurement configuration may include a job type. The job type may be logged minimization of drive test (MDT) measurements. The logged measurement configuration may include an event trigger. The event trigger may be "Out of Any Connectivity". The logged measurement configuration may specify a network type. The network type may be the at least one non-<NUM>-network service.

Determining connectivity may include, in the case of V2X, checking whether a PC5 interface is detectable. Determining connectivity may include, in the case of WLAN, checking whether a Wi-Fi beacons are detectable. Determining connectivity may include, in the case of NTN, checking whether a satellite signal is detectable.

The at least one non-<NUM>-network service includes all available non-<NUM>-network services. The at least one non-<NUM>-network service may include one or more non-3gpp networks. The one or more non-3gpp networks may include Bluetooth (BT).

In a second aspect of the present disclosure, an apparatus according to claim <NUM> is provided.

Determine connectivity may include, in the case of V2X, checking whether a PC5 interface is detectable. Determine connectivity may include, in the case of WLAN, checking whether a Wi-Fi beacons are detectable. Determine connectivity may include, in the case of NTN, checking whether a satellite signal is detectable.

In a further aspect of the present disclosure, a computer program product comprises a non-transitory computer-readable storage medium bearing computer program code embodied therein for use with a computer, the computer program code comprising code for performing: a method according to claim <NUM>.

In a sixth aspect of the present disclosure, a network comprises at least one apparatus as described above.

In some embodiments, the method further comprises: when connectivity over the at least one non-<NUM>-network service is not detected, entering an "Out of Any Connectivity" state; logging "Out of Any Connectivity" data; storing the "Out of Any Connectivity" data; when <NUM>-network coverage is detected, exiting from the "Out of Any Connectivity" state; reporting availability of logged "Out of Any Connectivity" data to the network node; and forwarding the logged "Out of Any Connectivity" data to the network node.

The at least one non-<NUM>-network service may include all available non-<NUM>-network services. The at least one non-<NUM>-network service may include one or more non-3gpp networks. The one or more non-3gpp networks may include Bluetooth (BT).

The foregoing and other aspects of these teachings are made more evident in the following detailed description, when read in conjunction with the attached drawing figures.

The invention is best understood with reference to <FIG>.

<FIG> is a block diagram of one possible and non-limiting example in which the subject matter of the present disclosure may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element(s) <NUM> are illustrated. In the example of <FIG>, the user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless device, such as a mobile device, that can access the wireless network. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured, with the one or more processors <NUM>, to cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> in this example is a base station that provides access to wireless devices, such as the UE <NUM>. The RAN node <NUM> may be, for example, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM> may be an NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control-plane protocol terminations towards the UE, and connected via the NG interface to a 5GC, such as, for example, the network element(s) <NUM>. The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. In one of several approaches, the NG-RAN node may include multiple network elements, which may also include a centralized unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or ng-eNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, for example, as part of a RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, for example, under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

The preceding paragraph describes one way of splitting the gNB functions: other splits are possible as well with different distributions of [LOW-PHY/HIGH-PHY/PHY]MAC/RLC/PDCP[/SDAP]/RRC functions across the various network nodes and different interfaces for connecting the network nodes.

The RAN node <NUM> includes a module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The module <NUM> may be implemented in hardware as module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, module <NUM> may be implemented as module <NUM>-<NUM>, which is implemented as computer program code <NUM> executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured, with the one or more processors <NUM>, to cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the CU <NUM>.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (e.g., a centralized unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

It is noted that description herein indicates that "cells" perform functions, but it should be clear that equipment which forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM>° area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So, if there are three <NUM>° cells per carrier and two carriers, then the base station has a total of six cells.

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to a network element <NUM>. The link <NUM> may be implemented as, for example, an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured, with the one or more processors <NUM>, to cause the network element <NUM> to perform one or more operations.

The computer-readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer-readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, and other functions as described herein.

The user equipment <NUM> may also refer to Internet of Things (IoT) devices, massive industrial networks, smart city infrastructure, wearable devices, networked medical devices, autonomous devices, etc. These types of UE devices may operate for extended periods of time without human intervention (e.g., perform maintenance, replace or recharge an on-device battery, etc.), may have reduced processing power and/or memory storage, may have reduced battery storage capability due to having small form factors, may be integrated into machinery (e.g., heavy machinery, factory machinery, sealed devices, etc.), may be installed/located in hazardous environment or difficult to access environments, etc..

<FIG> and <FIG> show an example of New Radio (NR) architecture having the <NUM> core (5GC) and the NG-RAN. The base stations gNB are coupled to the 5GC by the interface to core NGs, and the gNBs are coupled to each other by the inter-base station interface Xn.

As noted above, different types of UEs may have different connectivity to different networks and for different services. For example, an eMBB user may use an eMBB network, but also a Wi-Fi network or BT (Bluetooth). On the other hand, a V2X user may have two connections, such as eMBB and PC5.

At the present time, when a UE is in an RRC IDLE state and experiences a coverage hole in a radio network, the UE indicates this to the network in its MDT reports, by recording an "out of coverage" based on a radio signal loss, even though there might be coverage through another network type allowing the UE to "enjoy" the service. The indications on "out of coverage" state are limited to cell-based networks and <NUM> radio signal detection. They imply the user had no <NUM> radio coverage.

MDT reporting for "out of coverage" does not reflect any further infrastructure continuity on WLAN or through a PC5 interface, and thus does not bring any value to automated data collection for WLAN or V2X infrastuctures. It tends to underestimate communication capabilities of the WLAN or V2X traffic and does not provide insight on the service perception of an actual user. In the future, when NTN networks will provide satellite infrastructure support for <NUM>, the underestimation will also apply for this type of traffic.

Users, providing logged data collection from the same network area, will not reflect their real network perception in terms of whether they received service or not. Specifically, a regular eMBB user may lose network coverage <NUM> and experience an actual "out of coverage" state, while an underlying network <NUM>, such as WLAN, deployed at the coverage hole <NUM> or at the edge <NUM> of eMBB network may provide a service, and the user may be able to establish direct communication through supportive interface, such as Wi-Fi, as illustrated in <FIG>, which shows user equipments <NUM> out of NR signal coverage and in supportive network coverage.

On the other hand, a regular eMBB user may lose network coverage <NUM> and experience an actual "out of coverage" state, while an underlying network <NUM>, such as a WLAN, deployed at the coverage hole <NUM> or at the edge <NUM> of eMBB network may be unavailable, and the user may experience complete lack of any service, including Wi-Fi, as illustrated in <FIG>, which shows user equipments <NUM> out of NR signal coverage and disconnected from supportive network coverage.

In future deployments, such as cell-less deployments, there will be no means to know real coverage/service "holes", that is, where there is really a connectivity interruption. For network providers, who may jointly serve the different infrastuctures, the problem lies in the interpretation whether radio/cell loss is equivalent to absolute disconnectivity.

In the present disclosure, a new state, "Out of Any Connectivity", is introduced to allow the UE to monitor the state and to enter it once loss of any alternate connection, as defined by the network, occurs. The UE will enter this state when it has no connection to any other network type available.

To enable this feature, the UE capability needs to be defined for controlling the "Out of Any Connectivity" state and its logging, so that the UE can detect an underlying connectivity, such as in WLAN or PC5, in case of "out of radio coverage", and, when the UE is in the "Out of Any Connectivity" state, it will perform data logging on the state.

The present disclosed solution requires a UE to have the capability to detect and log the "Out of Any Connectivity" state. This implies that a UE, which is selected for MDT session logging, supports at least one more interface that enables alternate connectivity to a Uu interface and Logged MDT extensions in the context of MDT configuration and MDT reporting signaling. The solution focuses upon existing underlying networks, but does not limit the applicability to future deployments like NTN.

Detailed implementation can be categorized into following three steps:.

The data collection is triggered/configured from core network/OAM depending on the underlying connectivity. To achieve that, Trace Activation procedure from AMF/OAM to gNB can be extended to indicate "Out of Any Connectivity" parameter in jobType=Logged MDT. Also, RRC procedure for LoggedMeasurementConfiguration can be extended with new logged MDT event trigger, such as eventTriggered = outOfAnyConnectivity. This "Out of Any Connectivity" trigger can be configured per "service", for example, "Out of Any Connectivity" for "eMBB", "Out of Any Connectivity" for "V2X" users, etc. The configuration can also further indicate a per "service" trigger about which network types (out of the overall possible available networks) the UE should monitor in detecting "Out of Connectivity". This extends the configuration to tell the UE exactly which networks to monitor so that either "Out of Connectivity" is detected in all possible available networks if all of those are indicated for monitoring, which would be reflecting "Out of Any Connectivity" concept, or only for some of those, which would be reflecting "Out of Any Connectivity" in context of the given (predefined) networks alternate to radio to monitor after radio signal is lost. For instance, for the case of V2X service, it can be indicated that the UE should monitor all network types, such as PC5, BT, and WLAN, but the network may also ask more selectively detection of "Out of Connectivity" only for PC5 and WLAN or even only on PC5, as will be illustrated in Example <NUM> below.

Given the co-existence of parallel infrastructures, an operator or network provider may serve parallel deployments under the same core network, and may have an insight into what types of underlying connectivities are overlapping or neighboring with NR radio frequencies, thus, alternatively:.

The network may further indicate in the network types that the UE is also allowed to search for non-3gpp network types to determine connectivity, for example, through a field "non-3gpp" in the MDT configuration.

Logging in the UE starts by predefined connectivity trigger, for example according to configuration. If UE finds itself in out of NR radio coverage, it stores the information in internal memory. Out of NR coverage detection triggers monitoring of connectivity over other networks. If connectivity is found, "Out of Connectivity" state is not detected by the UE. If no other connectivity is found over available configured 3GPP connections, such as V2X, WLAN, satellite, and so forth, "Out of Any Connectivity" (or similarly "Out of Connectivity") is detected by the UE. For example,.

If no connectivity is found over available preconfigured connections, for example, when a V2X user was configured to monitor more selectively detection of "Out of Connectivity" only for PC5 while WLAN is out of interest, "Out of Any Connectivity" is detected based on a check for a single alternate network. For V2X connectivity, the UE checks whether PC5 interface is detectable. "Out of Connectivity" state term can optionally be used to distinguish from "Out of any Connectivity", where the UE, after radio signal loss, scans all other possible network types. In the "Out of Connectivity" option of UE implementation, the UE distinguishes the state when no connectivity was detected only on a given network, alternate to radio, that was given in the prior configuration. If no other connectivity is found over available configured 3GPP connections, such as V2X or satellite, "Out of Any Connectivity" detection triggers monitoring of connectivity over non-3gpp networks, such as Wi-Fi or BT. In every case where no connectivity is found, the UE enters the "Out of Any Connectivity" state and triggers "Out of Any Connectivity" logging with an indication of all the networks it tried that failed. UE needs to store in internal memory the intermediate results of "out of coverage" detection, which requires a different UE behavior and acting on the configuration, as will be illustrated in the Examples below.

Reporting of the information on "Out of Any Connectivity" relies on "UEInformationRequest" and "UEInformationResponse" messages with signaling extensions for "Out Of Any Connectivity" information, that also further maps to corresponding signaling onwards over network interfaces. The network here may retrieve "Out of Any Connectivity" information for only a set of network types by setting the "Out of Any Connectivity" request to monitor connectivity over those network types. <FIG> illustrates configuration and unsuccessful detection of the "Out of Any Connectivity" state for eMBB traffic:.

It should be noted that defining the state "Out of Any Connectivity" allows the network to trigger logging at the UE and final reporting of only a subset of the events that would be otherwise triggered under the "Out of Coverage" event. This helps the network to configure more focused logging at the UE, allowing the UE to log less information. <FIG> illustrates configuration and unsuccessful detection of the "Out of Any Connectivity" state for V2X traffic:.

Example <NUM>, illustrated in <FIG>, illustrates configuration and successful detection of the "Out of Any Connectivity" state for V2X traffic:.

Example <NUM>, illustrated in <FIG>, illustrates configuration and successful detection of the "Out of Any Connectivity" state for V2X traffic with selective configuration of the underlying network to monitor:.

With the disclosed solution, data contents are expected to be differentiated to provide reliable feedback on different services and better reflection of diverse <NUM> requirements, including the possibility to investigate WLAN, V2X, NTN (or any relevant network that support <NUM> deployments), user behaviors and experience in the co-existing networks.

<FIG> is a flow chart illustrating a method performed by a user equipment in one embodiment of the present disclosure. In block <NUM>, the user equipment receives, while in <NUM>-network coverage, a logged measurement configuration from a network node for use during a loss of <NUM>-network coverage. In block <NUM>, the user equipment determines connectivity over at least one non-<NUM>-network service. In block <NUM>, the user equipment stores, when connectivity over the non-<NUM>-network service is detected, "Out of <NUM> Radio Coverage" information. And, finally, in block <NUM>, the user equipment resumes, when <NUM>-network coverage is detected, monitoring <NUM>-network coverage.

<FIG> is a flow chart illustrating a method performed by a user equipment in another embodiment of the present disclosure. In block <NUM>, the user equipment receives, while in <NUM>-network coverage, a logged measurement configuration from a network node for use during a loss of <NUM>-network coverage. In block <NUM>, the user equipment determines connectivity over at least one non-<NUM>-network service. In block <NUM>, the user equipment enters, when connectivity over the at least one non-<NUM>-network service is not detected, an "Out of Any Connectivity" state. In block <NUM>, the user equipment logs "Out of Any Connectivity" data. In block <NUM>, the user equipment stores the "Out of Any Connectivity" data. In block <NUM>, the user equipment, when <NUM>-network coverage is detected, exits from the "Out of Any Connectivity" state. In block <NUM>, the user equipment reports availability of logged "Out of Any Connectivity" data to the network node. And, finally, in block <NUM>, the user equipment forwards the logged "Out of Any Connectivity" data to the network node.

For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device, although the exemplary embodiments are not limited thereto.

It should thus be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components, such as integrated circuit chips and modules, and that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit. The integrated circuit, or circuits, may comprise circuitry, as well as possibly firmware, for embodying at least one or more of a data processor or data processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. For example, while the exemplary embodiments have been described above in the context of advancements to the <NUM> NR system, it should be appreciated that the exemplary embodiments of this disclosure are not limited for use with only this one particular type of wireless communication system. The exemplary embodiments of the disclosure presented herein are explanatory and not exhaustive or otherwise limiting.

The following abbreviations may have been used in the preceding discussion:.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosed embodiments.

Claim 1:
An apparatus (<NUM>) at a User Equipment, said apparatus comprising
Means for receiving (<NUM>), while in <NUM>-network coverage, a logged measurement configuration from a network node for use during a loss of <NUM>-network coverage;
means for monitoring <NUM>-network coverage
means for detecting a loss of <NUM>-network coverage;
means for determining connectivity over at least one non-<NUM>-network service when <NUM> network coverage is detected to be lost;
means for storing (<NUM>) "Out of <NUM> Radio Coverage" information when connectivity over the non-<NUM>-network service is detected; and
means for resuming monitoring <NUM>-network coverage when <NUM>-network coverage is detected, wherein the logged measurement configuration specifies a network type, wherein the network type is the at least one non-<NUM>-network service and comprises one or more of vehicle-to-everything, V2X, wireless local area network, Wi-Fi, and non-terrestrial networks, NTN.