TW202420847A - Enhancements to mobility history information (mhi) for non-public networks (npn) - Google Patents

Abstract

Embodiments includes methods for a user equipment (UE) configured to operate in public networks and in non-public networks. Such methods include logging first mobility history information, MHI, associated with one or more public networks and/or with visited cells in the one or more public networks. Such methods include logging second MHI associated with one or more non-public networks and/or with visited cells in the one or more non-public networks. Such methods include, after subsequently connecting to a first network, sending to the first network one or more MHI reports that includes one or more of the following: at least part of the logged first MHI, and at least part of the logged second MHI. Other embodiments include complementary methods for a RAN node as well as UEs and RAN nodes configured to perform such methods.

Description

Enhancements to Mobile History Information (MHI) for Non-Public Networks (NPN)

The present invention relates generally to wireless communication networks, and more particularly to techniques for a network to use mobility history information (MHI) provided by a user equipment (UE) to estimate and/or determine various mobility characteristics of the UE.

Currently, fifth generation (5G) cellular systems, also known as New Radio (NR), are being standardized within the 3rd Generation Partnership Project (3GPP). 5G/NR is being developed for maximum flexibility to support multiple and substantially different use cases. In addition to the typical mobile broadband use cases, there are machine type communications (MTC), ultra-low latency critical communications (URLCC), sidelink device-to-device (D2D) and several other use cases.

5G/NR technology has many similarities with the fourth generation long term evolution (LTE). For example, NR uses CP-OFDM (Cyclic Preamble Orthogonal Frequency Division Multiplexing) in the DL and CP-OFDM or DFT-stretched OFDM (DFT-S-OFDM) in the UL. As another example, in the time domain, NR DL and UL physical resources are organized into 1-ms subframes of equal size. A subframe is further divided into multiple time slots of equal duration, where each time slot contains multiple OFDM-based symbols. An NR time slot may contain 14 OFDM symbols for a normal cyclic prefix and 12 symbols for an extended cyclic prefix. A resource block (RB) consists of a group of 12 consecutive OFDM subcarriers within a duration of a 12 or 14 symbol slot. A resource element (RE) corresponds to one OFDM subcarrier during one OFDM symbol interval.

Mobile History Information (MHI) was introduced in LTE and is also supported in NR. As part of its MHI measurement, a UE stores a cell identifier of its current serving cell and also stores information about how long the UE has stayed in this cell. The UE keeps this MHI for up to 16 previous serving cells. The UE MHI also contains information about how long the UE has been out of coverage.

As is known, 3GPP specifies that the technology be deployed in a public land mobile network (PLMN) accessible to any user with a valid subscription. 3GPP Release 16 (Rel-16) introduced support for non-public networks (NPNs), as described in 3GPP TS 23.501 (v16.5.0). An example NPN is a factory or other industrial facility that deploys its own 5GS to provide connectivity for both equipment and workers, where access by non-attached users is restricted.

When not relying on network functionality provided by a PLMN, the NPN can be deployed as a Standalone Non-Public Network (SNPN). A SNPN is identified by a PLMN ID and Network ID (NID) broadcasted in SIB1. An SNPN-capable UE supports the SNPN access mode. When the UE is configured to operate in the SNPN access mode, the UE simply selects a SNPN and registers with the SNPN. When the UE is not configured to operate in the SNPN access mode, the UE performs the normal PLMN selection procedure. A UE operating in the SNPN access mode only (re)selects cells within a selected/registered SNPN, and a cell is considered suitable only if the PLMN and NID broadcasted by the cell match the selected/registered SNPN.

Alternatively, the NPN may be deployed as a Public Network Integration (PNI) NPN when relying on functionality provided by a PLMN. For PNI-NPNs, a Closed Access Group (CAG) identifies a group of users that are allowed to access one or more cells associated with a CAG. A CAG is identified by a CAG identifier broadcast in SIB1. A CAG-capable UE may have the following depending on the PLMN configuration: ● An allowed CAG list containing CAG identifiers that the UE is allowed to access; and ● CAG-only indication if the UE is only allowed to access the 5GS via CAG cells.

The UE checks the suitability of the CAG cell based on the allowed CAG list provided by the upper layers. When the UE is configured with a CAG-only indication, only CAG member cells may be suitable. But if the UE is configured with a CAG-only indication for one of the PLMNs broadcast by the cell, an unsuitable cell may be accepted.

A UE may perform mobility procedures (e.g., handover) between a PLMN and an NPN. Generally speaking, a UE is successfully registered on an NPN (e.g., SNPN) when it has found an NPN cell suitable for camping and has accepted a registration from the UE in the registration area to which the camping cell belongs. A UE that accesses and subscribes to several networks or different network types (e.g., SNPN, PNI-NPN, and PLMN) may register on a private network (e.g., SNPN) as long as the UE can provide the services that require a specific subscription to register.

Even so, existing solutions specify UE MHI collection only in PLMN. Furthermore, when the UE collects information for MHI reporting, it is unable to distinguish between network types (e.g., NPN and PLMN) in NR. According to current specifications, when visiting a cell in an NPN, the UE does not discard the previously stored MHI of the PLMN cell and does not generate a new MHI for the cell of the NPN. Instead, the UE may add the newly visited NPN cell to the existing MHI, causing the UE to record and report an MHI that is a mix of PLMN and NPN visited cells. This may lead to various problems, disputes and/or difficulties.

One objective of embodiments of the present invention is to resolve these and other issues, issues and/or difficulties that may arise with UE MHI reporting, thereby enabling other advantageous deployments of 5GS-based NPNs.

Some embodiments include methods (eg, procedures) for a UE configured to operate in a public network (PN, such as a PLMN) and a non-public network (NPN).

The exemplary methods include recording a first MHI associated with one or more public networks and/or with visited cells in the one or more public networks. The exemplary methods include recording a second MHI associated with one or more non-public networks and/or with visited cells in the one or more non-public networks. The exemplary methods include, after subsequently connecting to a first network, sending one or more MHI reports to the first network, the one or more MHI reports including one or more of: at least a portion of the recorded first MHI; and at least a portion of the recorded second MHI.

In some embodiments, the recorded second MHI includes an indication of a duration that the UE spent outside a public network and one of: an indication of the duration spent in a non-public network; or an indication of the duration spent in a network whose type and/or identifier cannot be disclosed. In some such embodiments, when the recorded second MHI for a non-public network includes the indication of the duration spent in a non-public network, the recorded second MHI also includes an identifier of the non-public network.

In some embodiments, the recorded first MHI includes an indication of a duration that the UE spent outside a non-public network and one of: an indication of the duration spent in a public network; or an indication of the duration spent in a network whose type and/or identifier cannot be revealed.

In some embodiments, for each visited cell in a non-public network, the recorded second MHI includes an indication of a duration that the UE spent in the visited cell and one of: an indication that the visited cell is part of a non-public network; or an indication that the visited cell is part of a network whose type and/or identification code cannot be revealed.

In various embodiments, the one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least a portion of the first MHI but does not include the second MHI; ● a single MHI report that includes at least a portion of the second MHI but does not include the first MHI; ● a single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI; or ● a first MHI report that includes at least a portion of the first MHI and a second MHI report that includes at least a portion of the second MHI.

In some of these embodiments, when the first network is a public network, the at least portion of the first MHI included in the single MHI report corresponds to one of: ● all first MHIs recorded for all visited public networks and/or all visited cells in public networks; or ● only the first MHIs recorded for the first network and/or visited cells in the first network.

In other of these embodiments, when the first network is a non-public network, the at least a portion of the second MHI included in the single MHI report or the second MHI report corresponds to one of the following: ● All second MHIs recorded for all visited non-public networks and/or all visited cells in non-public networks; or ● Only the second MHI recorded for the first network and/or visited cells in the first network.

In some of these embodiments, these exemplary methods also include discarding the first MHI in response to the earlier of the following events after sending the single MHI report that includes at least a portion of the second MHI but does not include the first MHI: ● connecting to a second network that is a public network and sending the first MHI to the second network; or ● a time limit expires without sending the first MHI to a public network.

In some of these embodiments, for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, at least one entry in the MHI report is associated with a respective at least one visited cell. Each of the at least one entry indicates one of the following for the associated visited cell: ● Whether the visited cell is associated with a public network or a non-public network; or ● Whether information reported for the visited cell should be disclosed to other networks.

In some variations of these embodiments, each entry associated with a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell.

In some embodiments, the first MHI and the second MHI are recorded in separate UE variables. In other embodiments, the first MHI and the second MHI are recorded in a single UE variable.

In some embodiments, these exemplary methods also include, after subsequently connecting to the first network, receiving an information request for MHI recorded for public networks and MHI recorded for non-public networks from the first network. In this case, sending the one or more MHI reports is in response to the information request. In some of these embodiments, the information request includes a single indication of a request for MHI recorded for public networks and MHI recorded for non-public networks. In others of these embodiments, the information request includes a first indication of a request for MHI recorded for public networks and a second indication of a request for MHI recorded for non-public networks.

In some embodiments, the exemplary methods also include receiving a configuration for recording and reporting MHI from the first network or from a second network. In this case, recording the first and second MHIs and sending the one or more MHI reports are based on the configuration.

Other embodiments include additional methods (eg, processes) for a RAN node configured to operate in a first network.

These exemplary methods may include receiving one or more MHI reports from a UE, the one or more MHI reports including one or more of the following recorded by the UE: ● A first MHI associated with one or more visited public networks and/or visited cells in the one or more public networks, and ● A second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks.

The exemplary methods also include identifying a second RAN node based on the received one or more MHI reports. For example, the second RAN node serves one or more of the cells identified in the one or more MHI reports. The exemplary methods also include sending at least a portion of the received one or more MHI reports to the second RAN node.

In various embodiments, the first and second MHIs may have any of the same content, form and/or structure as the corresponding first and second MHIs recorded by a UE, as outlined above for the UE embodiment. Similarly, the one or more MHI reports may have any of the same content, form and/or structure as the corresponding one or more MHI reports outlined above for the UE embodiment.

In some embodiments, the first and second MHI reports are sent to the second RAN node as one of: separate fields of a single information element (IE) in a message; or separate IEs in the message.

In some embodiments, these exemplary methods also include sending an information request for MHI recorded for public networks and MHI recorded for non-public networks to the UE. In this case, receiving the one or more MHI reports is in response to the information request. In some of these embodiments, the information request includes a single indication of a request for MHI recorded for public networks and MHI recorded for non-public networks. In others of these embodiments, the information request includes a first indication of a request for MHI recorded for public networks and a second indication of a request for MHI recorded for non-public networks.

In some embodiments, the exemplary methods also include sending a configuration for recording and reporting MHI to the UE. The contents of the one or more MHI reports are based on the configuration.

In some embodiments, the RAN node and the second RAN node are configured to dually connect to the UE. In other embodiments, a cell served by the second RAN node is a target cell for a UE mobility procedure, and at least a portion of the received one or more MHI reports are sent to the second RAN node with the mobility procedure. In some embodiments, the second RAN node serves one or more of the cells identified in the one or more MHI reports.

Other embodiments include UEs (e.g., wireless devices, etc.) and RAN nodes (e.g., base stations, eNBs, gNBs, ng-eNBs, etc.) configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory computer-readable media storing computer-executable instructions that, when executed by processing circuits, configure such UEs and RAN nodes to perform operations corresponding to any of the exemplary methods described herein.

These and other embodiments described herein may provide various benefits and/or advantages. For example, embodiments may enable a network (e.g., a PLMN) to determine, based on the UE MHI, whether a UE is not connected to a network cell because it is not within the coverage of the network or because it is connected to an NPN but is still within the coverage. In addition, embodiments may prevent a UE from sending sensitive, confidential, and/or proprietary information about a visited NPN to a PLMN or another NPN. In embodiments where the UE provides this information, explicit marking of the NPN relationship may prevent a PLMN from sharing the information with other PLMNs and/or NPNs. In this way, embodiments may protect the privacy and security of users of NPNs and the like.

These and other objects, features, and advantages of the present invention will become apparent after reading the following detailed description in light of the drawings which are briefly described below.

The embodiments briefly summarized above will now be more fully described with reference to the accompanying drawings. These descriptions are provided by way of example to illustrate the subject matter to those skilled in the art and should not be construed as limiting the scope of the subject matter to only the embodiments described herein. More specifically, the examples provided below illustrate the operation of various embodiments according to the advantages discussed above.

In general, all terms used herein should be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant art, unless explicitly defined and/or a different meaning is implied from the context of use. All references to an element, device, component, member, step, etc. should be interpreted openly as referring to at least one instance of the element, device, component, member, step, etc., unless otherwise explicitly specified or explicitly implied from the context of use. The operations of any method and/or procedure disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as being after or before another operation and/or it is implied that an operation must be after or before another operation. Any feature of any embodiment disclosed herein may be applied to any other disclosed embodiment where appropriate. Likewise, any advantages of any embodiment described herein may, where appropriate, be applied to any other disclosed embodiment.

In addition, the following terms are used throughout the description given below: ●   Radio access node: As used herein, a "radio access node" (or equivalently "radio network node", "radio access network node" or "RAN node") may be any node in a radio access network (RAN) that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a gNB in a 3GPP 5G/NR network or an enhanced or eNB in a 3GPP LTE network), base station distributed components (e.g., CU and DU), a high power or macro base station, a low power base station (e.g., micro, pico, femto or home base station or the like), an integrated access backhaul (IAB) node, a transmission point (TP), a transmission reception point (TRP), a remote radio unit (RRU or RRH), and a relay node. ●   Core network node: As used herein, a "core network node" is any type of node in a core network. Some examples of a core network node include, for example, a mobility management entity (MME), a serving gateway (SGW), a PDN gateway (P-GW), a policy and charging rules function (PCRF), an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a charging function (CHF), a policy control function (PCF), an authentication server function (AUSF), a location management function (LMF), or the like. ●   Wireless device: As used herein, a "wireless device" (or simply "WD") is any type of device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Wireless communication may involve the transmission and/or reception of wireless signals using electromagnetic waves, radio waves, infrared waves and/or other types of signals suitable for conveying information through the air. Unless otherwise noted, the term "wireless device" is used interchangeably herein with the term "user equipment" (or "UE"), where both terms have a different meaning from the term "network node". ●   Radio node: As used herein, a "radio node" may be a "radio access node" (or equivalent term) or a "wireless device". ●   Network node: As used herein, a "network node" is any node that is part of a radio access network (e.g., a radio access node or equivalent term) or core network (e.g., a core network node discussed above) of a cellular communication network. Functionally, a network node is a device that is capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or devices in a cellular communication network to implement and/or provide radio access to wireless devices and/or perform other functions (e.g., management) in a cellular communication network. ●   Node: As used herein, the term "node" (without a prefix) may be any type of node that may be in or using a wireless network (including a RAN and/or core network), including a radio access node (or equivalent term), core network node, or wireless device. However, the term "node" may be limited to a specific type (e.g., radio access node, IAB node) based on its specific characteristics in any given context.

The above definitions are not intended to be exclusive. In other words, the same or similar terms may be used elsewhere in the present invention to illustrate and/or describe various terms of the above terms. However, to the extent that such other explanations and/or descriptions conflict with the above definitions, the above definitions shall prevail.

It should be noted that the description given herein focuses on a 3GPP cellular communication system and thus, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to a 3GPP system and may be applied to any communication system that may benefit therefrom. Furthermore, although the term "cell" is used herein, it should be understood (particularly with respect to 5G NR) that beams may be used instead of cells and thus, the concepts described herein apply equally to both cells and beams.

FIG. 1 shows a high-level view of an exemplary 5G network architecture consisting of a Next Generation Radio Access Network (NG-RAN, 199) and a 5G Core (5GC, 198). The NG-RAN may include one or more gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs (100, 150) connected via respective interfaces (102, 152). More specifically, the gNBs may be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG-C interfaces, and to one or more User Plane Functions (UPFs) in the 5GC via respective NG-U interfaces. The 5GC may include various other Network Functions (NFs), such as Session Management Functions (SMFs).

Although not shown, in some deployments, the 5GC may be replaced by an evolved packet core (EPC, 198), which is known to be used with a long term evolution (LTE) evolved UMTS RAN (E-UTRAN). In such deployments, the gNBs (e.g., 100, 150) may be connected to one or more mobility management entities (MMEs) in the EPC via respective S1-C interfaces and to one or more serving gateways (SGWs) in the EPC via respective NG-U interfaces.

In addition, the gNBs may be connected to each other via one or more Xn interfaces, such as the Xn interface (140) between gNBs (100, 150). The radio technology of NG-RAN is often referred to as "New Radio" (NR). With respect to the NR interface to the UE, each of the gNBs may support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. Each of the gNBs may serve a geographic coverage area comprising one or more cells, and in some cases may also use various directional beams to provide coverage in respective cells. Generally speaking, a DL "beam" is a coverage area of a network transmitted reference signal (RS) that can be measured or monitored by a UE.

NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). NG-RAN logical nodes and the interfaces between them are defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functionality are specified. TNL provides services for user plane transport and signaling transport.

An NG RAN logic node (e.g., gNB 100) includes a central unit (CU or gNB-CU, e.g., 110) and one or more distributed units (DU or gNB-DU, e.g., 120, 130). The CU is a logic node that hosts higher layer protocols and performs various gNB functions (such as controlling the operation of the DU). The DU is a distributed logic node that hosts lower layer protocols and may include various subsets of gNB functions depending on the functional split option. Each CU and DU may include various circuits required to perform their respective functions, including processing circuits, communication interface circuits (e.g., transceivers), and power supply circuits.

A gNB-CU is connected to one or more gNB-DUs via respective F1 logical interfaces (e.g., 122 and 132 shown in FIG. 1 ). However, a gNB-DU may only be connected to a single gNB-CU. The gNB-CU and its connected gNB-DU(s) are visible to other gNBs and the 5GC only as a gNB. In other words, the F1 interface is not visible outside the gNB-CU.

Centralized control plane protocols (e.g., PDCP-C and RRC) may be hosted in a CU different from centralized user plane protocols (e.g., PDCP-U). For example, a gNB-CU may be logically divided into a CU-CP function (including RRC and PDCP for signaling radio bearers) and a CU-UP function (including PDCP for UP). In a gNB, a single CU-CP may be associated with multiple CU-UPs. The CU-CP and CU-UP communicate with each other using the E1-AP protocol over the E1 interface. In addition, the F1 interface between the CU and the DU (see Figure 1) is functionally divided into F1-C between the DU and the CU-CP and F1-U between the DU and the CU-UP. The three deployment cases of the split gNB architecture shown in Figure 1 are CU-CP and CU-UP centralized, CU-CP distributed/CU-UP centralized, and CU-CP centralized/CU-UP distributed.

FIG2 shows another high-level view of an exemplary 5G network architecture including an NG-RAN (299) and a 5GC (298). As shown in the figure, the NG-RAN may include gNBs (e.g., 210a, 210b) and ng-eNBs (e.g., 220a, 220b) interconnected to each other via respective Xn interfaces. The gNBs and ng-eNBs are also connected to the 5GC via NG interfaces, more specifically to the access and mobility management function (AMF, e.g., 230a, 230b) via respective NG-C interfaces and to the user plane function (UPF, e.g., 240a, 240b) via respective NG-U interfaces. In addition, the AMF may communicate with the policy control function (PCF, e.g., 250a, 250b) and the network exposure function (NEF, e.g., 260a, 260b).

Each of the gNBs may support an NR radio interface plane including frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. Each of the ng-eNBs may support a fourth generation (4G) long term evolution (LTE) radio interface plane. However, unlike conventional LTE eNBs, the ng-eNB is connected to the 5GC via an NG interface. Each of the gNBs and ng-eNBs may serve a geographic coverage area (e.g., 211a to 211b, 221a to 221b) including one or more cells. Depending on the cell in which it is located, a UE (205) may communicate with the gNB or ng-eNB serving the cell via an NR or LTE radio interface plane, respectively. Although FIG. 2 shows the gNB and ng-eNB separately, a single NG-RAN node may also provide both types of functionality.

In addition to providing coverage via cells as in LTE, NR networks also provide coverage via "beams." In general, a downlink (DL, i.e., network to UE) "beam" is a coverage area of a network-transmitted reference signal (RS) that can be measured or monitored by a UE. For example, in NR, RS may include any of the following: synchronization signal/PBCH block (SSB), channel state information RS (CSI-RS), tertiary reference signal (or any other synchronization signal), positioning RS (PRS), demodulation RS (DMRS), phase tracking reference signal (PTRS), etc. In general, SSBs are available to all UEs regardless of their connection status to the network, while other RS (e.g., CSI-RS, DM-RS, PTRS) are associated with specific UEs with a network connection.

FIG3 shows an exemplary configuration of the NR User Plane (UP) and Control Plane (CP) protocol stacks between a UE (310), a gNB (320), and an AMF (330) (such as those shown in FIGS. 1-2). The physical (PHY), medium access control (MAC), radio link control (RLC), and packet data convergence protocol (PDCP) layers between the UE and the gNB are common to the UP and CP. PDCP provides ciphering/deciphering, integrity protection, sequence numbering, reordering, and duplicate detection for both the CP and the UP. In addition, PDCP provides header compression and retransmission for UP data.

On the UP side, Internet Protocol (IP) packets arrive at PDCP as Service Data Units (SDUs), and PDCP generates Protocol Data Units (PDUs) for delivery to RLC. The Service Data Adaptation Protocol (SDAP) layer handles Quality of Service (QoS), including mapping between QoS flows and Data Radio Bearers (DRBs) and marking QoS Flow Identifiers (QFIs) in UL and DL packets. RLC delivers PDCP PDUs to MAC via Logical Channels (LCH). RLC provides error detection/correction, concatenation, segmentation/reassembly, sequence numbering, and reordering of data sent to/from upper layers. The MAC provides mapping between LCH and PHY transport channels, LCH prioritization, multiplexing to or demultiplexing from transport blocks (TBs), hybrid ARQ (HARQ) error correction, and dynamic scheduling (on the gNB side). The PHY provides transport channel services to the MAC and processes the transmission on the NR radio interface plane, such as through modulation, coding, antenna mapping, and beamforming.

On the CP side, the Non-Access Stratum (NAS) layer is between the UE and the AMF and handles UE/gNB authentication, mobility management, and security control. The RRC is located below the NAS in the UE, but terminates at the gNB instead of the AMF. The RRC controls the communication between the UE and the gNB and the mobility of a UE between cells in the NG-RAN at the radio interface plane. The RRC also broadcasts system information (SI) and performs the establishment, configuration, maintenance, and release of DRBs and signaling radio bearers (SRBs) and is used by the UE. In addition, the RRC controls the addition, modification, and release of carrier aggregation (CA) and dual connectivity (DC) configurations of the UE, and performs various security functions such as key management.

After a UE is powered on, it will be in the RRC_IDLE state until an RRC connection is established with the network, at which point the UE will transition to the RRC_CONNECTED state (e.g., where data transfer can occur). The UE returns to RRC_IDLE after releasing the connection with the network. In the RRC_IDLE state, the UE's radio is active on a discontinuous reception (DRX) schedule configured by upper layers. During the DRX active period (also known as the "DRX on duration"), an RRC_IDLE UE receives SI information broadcast in the cell where the UE is camping, performs measurements of neighboring cells to support cell reselection, and monitors a paging channel on the PDCCH via the gNB for paging from the 5GC. The gNB of the cell where the serving UE is camped is not aware of an NR UE in RRC_IDLE state. However, NR RRC includes an RRC_INACTIVE state where the serving gNB is aware of a UE (e.g., via UE context). RRC_INACTIVE has some properties similar to a “pause” condition used in LTE.

Seamless mobility is a key feature of 3GPP Radio Access Technologies (RATs). Generally speaking, a RAN (e.g., NG-RAN) configures a UE to perform and report Radio Resource Management (RRM) measurements to assist in network controlled mobility decisions, such as for handover from a serving cell to a neighboring cell. Seamless handover ensures that the UE moves around the coverage area of different cells without excessive interruption of data transmission. However, there will be cases where the network fails to handover the UE to the "correct" neighboring cell in a timely manner, which may cause the UE to declare a Radio Link Failure ("RLF") or Handover Failure ("HOF"). This may occur before the UE sends a measurement report in a source cell, before the UE receives a handover command to a target cell, shortly after the UE performs a successful handover to the target cell, or after a HOF to the target cell (e.g., after timer T304 expires, when the UE starts synchronizing with the target cell).

A RLF reporting procedure was introduced in LTE Rel-9 as part of Mobility Robustness Optimization (MRO). In this procedure, a UE records relevant information at the time of RLF and subsequently reports this information to the network via a target cell to which the UE is finally connected (e.g., after reestablishment). The reported information may include RRM measurements of various neighboring cells before a mobility operation (e.g., handover). 3GPP Rel-17 introduced a Successful Handover Report (SHR), whereby a UE reports various information about a successful handover to a target cell.

For example, both the RLF report and the SHR may include information about the UE's random access towards the target cell. The random access (RA) information may include the bandwidth part (BWP) for the attempted RA, the DL path loss experienced when initiating the RA procedure, and information related to each RA preamble transmission attempt (e.g., whether contention was experienced, the number of preamble transmission attempts in a certain SSB or CSI-RS, etc.).

3GPP TS 38.331 (v17.1.0) section 5.7.10.4 describes the UE actions after a successful completion of an RA procedure, including the various RA information collected and stored in the UE variable VarRA-Report . A UE may release (i.e., discard) the VarRA-Report 48 hours after the last successful RA procedure or failed/successful on-demand SI acquisition procedure, where the information is added to the stored VarRA-Report .

Mobile History Information (MHI) was introduced in LTE and is also supported in NR. As part of its MHI measurement, a UE stores a cell identifier of its current serving cell and also stores information about how long the UE has stayed in this cell. The UE keeps this MHI for up to 16 previous serving cells. The UE MHI also contains information about how long the UE has been out of coverage.

3GPP TS 38.331 (v17.1.0) section 5.7.9 describes UE MHI collection in more detail, including how the UE accumulates MHI in RRC_CONNECTED, RRC_IDLE and RRC_INACTIVE states. In response to waiting to access or connecting to a different cell ("visited cell"), the UE may, if necessary, include an entry for the visited cell in the visitedCellInfoList of the UE variable VarMobilityHistoryReport after removing the oldest entry.

3GPP TS 38.331 (v17.1.0) section 6.3.4 specifies the VisitedCellInfoList information element (IE), which is also shown as an ASN.1 data structure in Figure 4. This IE contains the MHI of up to 16 most recently visited primary cells or the time spent in any cell selection state and/or camped on any cell state in NR or E-UTRA, and the MHI of the maxPSCellHistory most recently visited primary secondary cell group cells across all primary cells included in the VisitedCellInfoList in case of dual connectivity. The most recently visited cells are stored first in the list. The list includes cells visited in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED states for NR and cells visited in RRC_IDLE and RRC_CONNECTED states for LTE/E-UTRA.

A UE may indicate the availability of MHI via the mobilityHistoryAvail field in various RRC messages, including RRCSetupComplete , RRCReestablishmentComplete , and RRCResume-Complete . After being notified of the availability of MHI, the network may initiate a UE information procedure to obtain MHI from the UE. 3GPP TS 38.331 (v17.1.0) section 5.7.10 (including subsections) specifies the UE information procedure in more detail.

The network initiates this procedure by sending a UEInformationRequest message to the UE. FIG. 5 shows an ASN.1 data structure of an exemplary UEInformationRequest message, which is further described in 3GPP TS 38.331 (v17.1.0) section 6.3.4. It should be noted that the mobilityHistoryReportReq-r16 field in the UEInformationRequest-r16-IE is an optional field, but if present, it is set to "true", thereby indicating that the network requests available MHI from the UE. Its absence indicates that the network has not requested MHI. A similar convention is used for the ra-ReportReq-r16 field associated with RA information. In addition, the message contains fields for the network to request various other information following similar conventions.

After receiving the UEInformationRequest message, the UE responds with a UEInformationResponse message containing the requested information. FIG. 6 shows an ASN.1 data structure of an exemplary UEInformationResponse message, which is further described in 3GPP TS 38.331 (v17.1.0) section 6.3.4. It should be noted that the various report fields (e.g., ra-ReportList-r16 , rlf-Report-r16 , mobilityHistoryReport-r16 , etc.) are optional, but if included, they contain various relevant information recorded by the UE.

As mentioned above, 3GPP-specified technologies have traditionally been deployed in PLMNs (also known as public networks, PNs) that are accessible to any user with a valid subscription. 3GPP Rel-16 introduced support for non-public networks (NPNs), as described in 3GPP TS 23.501 (v16.5.0). An example NPN is a factory or other industrial facility that deploys its own 5GS to provide connectivity for both equipment and workers, where access by non-attached users is restricted.

When not relying on network functionality provided by a PLMN, an NPN can be deployed as a Standalone Non-Public Network (SNPN). A SNPN is identified by a PLMN ID and Network ID (NID) broadcasted in SIB1. Alternatively, when relying on functionality provided by a PLMN, an NPN can be deployed as a Public Network Integration (PNI) NPN. A PNI NPN is identified by a PLMN ID and Closed Access Group (CAG) identifier broadcasted in SIB1.

Even so, existing solutions specify UE MHI collection only in PLMN. Furthermore, when the UE collects information for MHI reporting, it is unable to distinguish between network types (e.g., NPN and PLMN) in NR. According to current specifications, when visiting a cell in an NPN, the UE does not discard the previously stored MHI of the PLMN cell and does not generate a new MHI for the cell of the NPN. Instead, the UE may add the newly visited NPN cell to the existing MHI, causing the UE to record and report an MHI that is a mix of PLMN and NPN visited cells. This may lead to various problems, disputes and/or difficulties.

For example, such operation of the UE may expose sensitive, confidential and/or proprietary information about a visited NPN to a PLMN or another NPN. This may put the privacy of UEs connected to the NPN at risk. As a more specific example, if a SNPN is managed to avoid interaction and information exposure with other networks, a UE that collects and reports the MHI of a visited cell in the SNPN may expose the SNPN's cell ID, location, coverage details, etc. to other networks. This may create external security risks for the SNPN and its users.

Embodiments of the present invention address these and other problems, issues and/or difficulties by providing a technique in which a UE collects visited cell information of an MHI by network type (i.e., visited PN cells in a PN-related MHI and visited NPN cell information in an NPN-related MHI). In some embodiments, the UE also records the time spent in each network and a flag indicating that the UE spent the recorded time in an NPN. In other embodiments, the UE records the network identifier in each MHI so that it can be reported to the appropriate network. In other embodiments, the UE records the time spent in another network without specifying which network it is. In other embodiments, the UE may record the visited NPN cell in the PN-related MHI, but in addition to or instead of the physical cell identifier (PCI) and frequency information, also include the cell global identifier (CGI) of the visited cell.

The disclosed embodiments may provide various benefits and/or advantages. For example, embodiments may enable a network (e.g., a PLMN) to determine, based on the UE MHI, whether a UE is not connected to a network cell because it is not within the coverage of the network or because it is connected to an NPN but is still within the coverage. In addition, embodiments may prevent a UE from sending sensitive, confidential, and/or proprietary information about a visited NPN to a PLMN or another NPN. In embodiments where the UE provides this information, explicit marking of the NPN relationship may prevent a PLMN from sharing the information with other PLMNs and/or NPNs. In this way, embodiments may protect the privacy and security of users of NPNs and the like.

Some embodiments include methods performed by a UE capable of moving between public and non-public networks (e.g., PLMN and NPN). In these embodiments, the UE is configured by the network (e.g., PLMN) with instructions for handling visited cell information of the NPN that can potentially be included in the UE's reported MHI. In some embodiments, the UE may also be configured with instructions for handling visited cell information of the PLMN. After visiting a cell in an NPN or a PLMN, the UE manages the collection of the MHI according to the configured instructions.

In some embodiments, the UE is configured not to include in the same MHI report the MHI of visited cells associated with different network types (i.e., public and non-public) or different networks of the same type (e.g., two NPNs). This restriction may prevent sensitive, confidential, and/or proprietary information about a visited NPN from being transmitted to a PLMN or another NPN. Information protected in this manner may include, for example, measurements and other information that enable an entity to track users in the NPN.

In some variants, this restriction may be limited to not including the visited NPN cell in an MHI report sent to a PN or another NPN, so that the UE may include the visited PN cell in an MHI report sent to an NPN.

In some embodiments, the configuration may indicate one or more specific networks (e.g., PLMN IDs) to which the restriction policy applies. In some embodiments, the configuration may indicate specific types of cell information that should be included or excluded from an MHI report. For example, in the case of dual connectivity (DC) with a master cell group (MCG) and a secondary cell group (SCG), the configuration may indicate whether the identifier of the visited primary SCG cell (PSCell) should be included along with the identifier of the visited PCell (i.e., MCG).

In some embodiments, the UE records the time spent in an NPN and an indication of the time spent in the NPN. In other embodiments, the UE records the time spent in a network whose information should not be disclosed, without providing information identifying the specific network (or network type) visited by the UE.

In other embodiments, the UE is configured to include information about visited cells associated with different network types (i.e., public and non-public) or different networks of the same type (e.g., two NPNs) in the same MHI report. In this case, the UE is also configured to include the cell global identifier (CGI) associated with the visited NPN cell in the MHI, which also includes information about the visited PN cell.

In other embodiments, the UE is configured to provide MHI for a specific network (which may be a PLMN, SNPN or PNI-NPN) only when served by the network, wherein the provided MHI only includes the visited cells of the specific network. In this case, the UE must record the visited cell information as well as the network identifier (e.g., PLMN ID).

In summary, once configured, a UE stores up to a maximum number of cells (e.g., PCell) recently visited in RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED states associated with a network type (e.g., PN or NPN) according to the configuration. When reporting PN and/or NPN information in the MHI, a UE capable of moving between PN and NPN follows the configuration and policy options described above.

FIG. 7 shows an ASN.1 data structure of an exemplary VisitedCellInfoList IE according to some embodiments of the present invention. The VisitedCellInfoList contains up to a maximum number (16) VisitedCellInfo IEs, each of which contains information about a visited cell. In these embodiments, each VisitedCellInfo IE contains a networkType-r18 field, which can take two different enumerated values: "PN", which indicates that the visited cell is associated with a public network; and "SNPN", which indicates that the visited cell is associated with a SNPN.

FIG8 shows an ASN.1 data structure of another exemplary VisitedCellInfoList IE according to other embodiments of the present invention. In these embodiments, each VisitedCellInfo IE includes a privateNetwork-r18 field, which indicates that the visited cell is associated with an NPN when present, and indicates that the visited cell is associated with a public network when not present.

FIG9 shows an ASN.1 data structure of another exemplary VisitedCellInfoList IE according to other embodiments of the present invention. In these embodiments, each VisitedCellInfo IE includes only one of the following (by selection): an nr-CellId-r16 field, which includes information about a visited NR cell; an eutra-CellId-r16 field, which includes information about a visited LTE cell; and a notDisclosedCellInfo field, which indicates information about a visited cell that cannot be disclosed (but does not specify the reason, such as being part of a SNPN).

Embodiments may also be implemented as text included in a 3GPP specification. For example, some exemplary text that may be added to the description of the UE MHI procedure in 3GPP TS 38.331 (17.1.0) is shown below, where ellipses indicate existing text that has been omitted for brevity. ***Beginning Proposed 3GPP Specification Text*** 5.7.9 Mobility History Data 5.7.9.1 General This procedure specifies how the UE stores mobility history information, including RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED. 5.7.9.2 Start If the UE supports storage of mobility history information, the UE shall: … 1＞ After entering NR PN (in RRC_CONNECTED or RRC_IDLE) when previously using another network type (e.g. SNPN); or: 1＞ After entering NR SNPN (in RRC_CONNECTED or RRC_IDLE) when previously using another network type (e.g. PN): 2＞ If necessary, include an entry in the variable VarMobilityHistoryReport , after removing the oldest entry, based on the following: 3＞ Set the field timeSpent of the entry to the time spent outside the current network type; 3＞ Set the entry's NetworkType field to the selected network type to which the UE was connected before entering the current network type (in RRC_CONNECTED, RRC_IDLE or RRC_INACTIVE). ***END OF PROPOSED 3GPP SPECIFICATION TEXT***

In embodiments where the UE includes visited primary cells of a first and second network types (i.e., PN and NPN) in the same MHI report, the UE may be configured (or it may be specified) to record CGI information for cells of the second network type in an MHI report sent to one of the networks of the first network type. Exemplary text for these embodiments according to the description of the UE MHI procedures that may be added to 3GPP TS 38.331 (17.1.0) is shown below, where ellipses represent existing text that has been omitted for brevity. ***Beginning Proposed 3GPP Specification Text*** 5.7.9 Mobility History Data 5.7.9.1 General This procedure specifies how the UE stores mobility history information, including RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED. 5.7.9.2 Initialization If the UE supports storage of mobility history information, the UE shall: … 1＞ upon change of a suitable cell consisting of a SNPN PCell in RRC_CONNECTED (for NR cell) or a serving cell in RRC_INACTIVE (for NR cell) or RRC_IDLE (for NR or E-UTRA cell) to another NR, or when entering the “any cell selection” state from the “normal standby” state in NR, or when entering the “any cell selection” state from a suitable cell in RRC_CONNECTED state in NR: 2＞ include an entry in the visitedCellInfoList of the variable VarMobilityHistoryReport , possibly after removing the oldest entry, as required, according to the following: 3＞ include the previous SNPN in the field visitedCellId of the entry. PCell/Global Cell Identifier for Serving Cell; ***END OF PROPOSED 3GPP SPECIFICATION TEXT***

In other embodiments, the UE records information about the visited primary cells of the first and second network types (e.g., PN and NPN) in different UE variables. For example, the UE records information about the visited PN cells in an existing VarMobilityHistoryReport and records information about the visited NPN cells in a new variable (e.g., VarMobilityHistoryNPNReport or the like).

In some variants, the UE reports information about visited NPN cells to the NPN after registering with the network (e.g., VarMobilityHistoryNPNReport ). In other variants, the UE reports information about visited NPN cells to a PLMN (e.g., VarMobilityHistoryNPNReport ) after the network requests it (e.g., based on a confidentiality agreement between the PLMN and the NPN operator).

In some embodiments, the UE retains a VarMobilityHistoryReport with information about the visited PN cells after leaving the PN (e.g., registering with an NPN), and deletes it if the UE does not return to the PN within a time limit.

Figure 10 shows an ASN.1 data structure of an exemplary UEInformationRequest message according to some embodiments of the present invention. This message includes an optional mobilityHistoryReportReqSNPN-r16 field, which, when present, indicates that the network requests available SNPN MHI from the UE. Its absence indicates that the network has not requested SNPN MHI. It should be noted that this field is an addition to the mobilityHistoryReportReq-r16 field, by which the network requests available PN MHI from the UE in the manner described above with respect to Figure 5. The following shows exemplary text of these embodiments according to the description of the UE information procedure that can be added to 3GPP TS 38.331 (17.1.0), where ellipsis indicates existing text omitted for brevity. ***Begin proposed 3GPP specification text*** 5.7.10 UE Information The UE Information procedure is used by the network to request the UE to report information. 5.7.9.1 General This procedure specifies how the UE stores mobility history information, including RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED. 5.7.10.2 Initiation The network initiates the procedure by sending a UEInformationRequest message. The network shall only initiate this procedure after a successful secure start. 5.7.10.3 Reception of UEInformationRequest message After receiving a UEInformationRequest message, the UE shall, only after successful secure start: … 1> If mobilityHistoryReportReqforSNPN is set to TRUE: 2> Include mobilityHistoryReport and set it to include visitedCellInfoList from VarMobilityHistoryReportSNPN ; 2> Optionally, after removing the oldest entry, include an entry for the current SNPN PCell in mobilityHistoryReport and set its fields as follows: 3> Set visitedCellId to the global cell identifier or physical cell identifier and carrier frequency of the current PCell: … 1> If logMeasReport was included in UEInformationResponse : 2> Pass the UEInformationResponse message to lower layers for transmission via SRB2; 2> After successfully delivering the UEInformationResponse message acknowledged by the lower layer, discard the recorded measurement entries contained in the logMeasInfoList from VarLogMeasReport ; 1> Otherwise: 2> Pass the UEInformationResponse message to the lower layer for transmission via SRB1. ***End of proposed 3GPP specification text***

Other embodiments include a method performed by a RAN node. After receiving an MHI report (e.g., mobilityHistoryReportNPN IE) containing information about visited cells in an NPN from a UE, the RAN node identifies a second RAN node based on the cell identifier in the MHI and sends the received MHI to the identified second RAN node, which can use it for mobility robustness optimization (MRO), coverage and capacity optimization (CCO), or other improvements.

In some embodiments, the UE may be in dual connectivity, with a RAN node acting as a MN and a second RAN node acting as a SN. In this case, the MN sends the MHI received from the UE to the SN. Alternatively, the SN may receive the MHI from the UE and send it to the MN.

In other embodiments, the second RAN node may be the target node of a mobility procedure (e.g., handover) involving the UE generating the MHI. In this case, the RAN node may send the received MHI to the second RAN node during the mobility procedure, for example, as part of a handover request message.

The following text illustrates an example of how various embodiments may be specified in 3GPP TS 38.473 (v17.1.0) based on the addition of an optional NR mobility history report for the NPN field. 3GPP TS 38.423 (v17.1.0) that specifies the Xn interface between RAN nodes may be modified in a similar manner. For example, the UE History Information IE defined in 3GPP TS 38.423 (v17.1.0) may be modified to include a new container with NPN information. ***Begin Proposed 3GPP Specification Text*** 9.2.3.110 UE History Information from UE This IE contains information about a mobility history report for a UE. IE/Group Name Pres. Scope IE Type/Reference Semantic Description Select UE History from UE M ＞NR ＞＞NR movement history report M Octet string The VisitedCellInfoList (TS 38.331 [10]) contained in the UEInformationResponse message. ＞＞NPN NR movement history report O Octet string The VisitedCellInfoList contained in the UEInformationResponse message contains movement history collected in a non-public network (TS 38.331 [10]). ***END OF PROPOSED 3GPP SPECIFICATION TEXT***

Alternatively, the information in the NR Mobility History Report for NPN may be included in a separate IE, e.g., Non-Public Network UE History Information. The following text illustrates one example of how such embodiments may be specified in 3GPP TS 38.473 (v17.1.0) and 38.423 (v17.1.0) based on the addition of the optional NR Mobility History Report for NPN IE. ***Begin Proposed 3GPP Specification Text*** 9.3.1.x Non-Public Network UE History Information IE/Group Name Pres. Scope IE Type/Reference Semantic Description NPN NR Mobile History Report O Octet string The VisitedCellInfoList contained in the UEInformationResponse message contains movement history collected in a non-public network (TS 38.331 [10]). ***END OF PROPOSED 3GPP SPECIFICATION TEXT***

In other embodiments, the existing UE History Information IE (as defined in 3GPP TS 38.423 (v17.1.0)) may be modified to take into account the strategy applied by the UE when collecting and reporting MHI (e.g., as shown in Figure 9). The following text illustrates an example of how such embodiments may be specified in 3GPP TS 38.423 (v17.1.0). ***Beginning of proposed 3GPP specification text*** 9.2.3.64 UE History Information The UE History Information IE contains information about cells that a UE has served in an active state before a target cell. The entire mechanism is described in TS 36.300 [12]. Note: The definition of this IE is consistent with the definition of the UE History Information IE in TS 38.413 [5]. IE/Group Name Pres. Scope IE Type/Reference Semantic Description List of communities visited last 1..＜maxnoofCellsinUEHistoryInfo＞ The most recent information is added to the top of this list ＞Last visited community information M 9.2.3.65 Range Constraints instruction maxnoofCellsinUEHistoryInfo The maximum number of last visited cell information records that can be reported in IE. The value is 16. 9.2.3.65 Last Visited Cell Information The last visited cell information may contain cell specific information. IE/Group Name Pres. Scope IE Type/Reference Semantic Description Select the last visited community information M ＞NG-RAN Cell ＞＞Last interviewed NG-RAN cell information M Octet string Defined in TS 38.413 [5]. ＞E-UTRAN Cell ＞＞Last visited E-UTRAN cell information M Octet string Defined in TS 36.413 [31]. ＞UTRAN Cell ＞＞Last visited UTRAN cell information M Octet string Defined in TS 25.413 [32]. ＞GERAN Community ＞＞Last interviewed GERAN community information M Octet string Defined in TS 36.413 [31]. ＞No community information disclosed Enumeration (true, ...) ＞＞The last community interviewed did not reveal M ***END OF PROPOSED 3GPP SPECIFICATION TEXT***

The embodiments described above may be further illustrated with reference to FIGS. 11 to 14 , which depict exemplary methods (e.g., procedures) performed by a UE or RAN node. In other words, various features of the operations described below correspond to various embodiments described above. Some of the exemplary methods shown in FIGS. 11 to 14 may complement each other such that they may be used in conjunction to provide various benefits, advantages, and/or solutions to the problems described herein. Although the exemplary methods are illustrated in FIGS. 11 to 14 by specific blocks in a specific order, the operations corresponding to the blocks may be performed in a different order than shown and may be combined and/or divided into operations having different functionality than shown. Optional blocks and/or operations are indicated by dashed lines.

More specifically, FIG. 11 illustrates an exemplary method (e.g., procedure) for a user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN) according to various embodiments of the present invention. For example, the exemplary method shown in FIG. 11 may be performed by a UE (e.g., a wireless device) described with reference to other figures herein.

The exemplary method may include the operation of block 1120, wherein when visiting one or more cells of the one or more PNs, the UE may record a first MHI associated with the visited PN cell. The exemplary method may also include the operation of block 1130, wherein when visiting one or more cells of the one or more NPNs, the UE may record a second MHI associated with the visited NPN cell. The exemplary method may also include the operation of block 1150, wherein after subsequently connecting to a first network, the UE may send one or more MHI reports to the first network, the one or more MHI reports including one or more of: at least a portion of the first MHI; and at least a portion of the second MHI.

In some embodiments, when the first network is a PN, one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least part of the first MHI but does not include the second MHI; ● a single MHI report that includes the first MHI and the second MHI; or ● a first MHI report that includes the first MHI and a second MHI report that includes the second MHI.

In some of these embodiments, at least a portion of the first MHI included in the single MHI report corresponds to one of: ● all of the first MHI collected for all of the visited PN cells; or ● only the first MHI collected for the visited PN cells associated with the first network.

In some embodiments, when the first network is an NPN, one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least a portion of the second MHI but does not include the first MHI; ● a single MHI report that includes the first MHI and the second MHI; or ● a first MHI report that includes the first MHI and a second MHI report that includes at least a portion of the second MHI.

In some of these embodiments, at least a portion of the second MHI included in the single MHI report or the second MHI report corresponds to one of: ● all second MHIs collected for all visited NPN cells; or ● second MHIs collected only for visited NPN cells associated with the first network.

In some such embodiments, the exemplary method may also include the operation of block 1160, wherein after sending a single MHI report that includes at least a portion of the second MHI but does not include the first MHI (e.g., in block 1150), the UE may delete the first MHI in response to the earlier of the following events: ● connecting to a second network as a PN and sending the first MHI to the second network; or ● a time limit expires without sending the first MHI to a PN.

In some embodiments, for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, each MHI report entry corresponds to a visited cell and indicates one of the following for the visited cell: ● Whether the visited cell is associated with a PN or an NPN (e.g., as shown in FIGS. 7-8 ); or ● Whether information reported for the visited cell should be disclosed to other networks (e.g., as shown in FIG. 9 ).

In some of these embodiments, each MHI report entry corresponding to a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell.

In some embodiments, each MHI reporting entry corresponding to a visited NPN cell includes a first indication of a duration that the UE spent in the visited NPN cell and a second indication that the visited NPN cell is associated with one of: an NPN; or a network and/or a network type that cannot be disclosed.

In different embodiments, the first MHI and the second MHI may be recorded in separate UE variables or a single UE variable.

In some embodiments, the exemplary method may also include the operation of block 1140, wherein after subsequently connecting to the first network, the UE may receive an information request for an MHI for PN records and an MHI for NPN records from the first network. In this case, sending one or more MHI reports in block 1150 is in response to the information request. In various embodiments, the information request includes one of the following: ● A single indication of a request for an MHI for PN records and an MHI for NPN records; or ● A first indication of a request for an MHI for PN records and a second indication of a request for an MHI for NPN records.

In some embodiments, the exemplary method may also include the operation of block 1110, wherein the UE may receive a configuration for recording and reporting MHI from the first network or from a second network. In this case, recording the first and second MHIs (e.g., in blocks 1120 to 1130) and sending one or more MHI reports (e.g., in block 1150) is based on the configuration.

In addition, FIG12 illustrates an exemplary method (e.g., process) for a RAN node in a first network according to various embodiments of the present invention. For example, the exemplary method shown in FIG12 may be performed by a RAN node (e.g., base station, eNB, gNB, ng-eNB, etc.), as described elsewhere herein.

An exemplary method may include the operations of block 1230, wherein a RAN node may receive one or more MHI reports from a UE, the one or more MHI reports including one or more of the following: ● At least a portion of a first MHI recorded by the UE when visiting cells in one or more public networks (PNs), and ● At least a portion of a second MHI recorded by the UE when visiting cells in one or more non-public networks (NPNs);

The exemplary method may also include operations of block 1240, where the RAN node may identify a second RAN node based on the received one or more MHI reports. For example, the second RAN node serves one or more of the cells identified in the one or more MHI reports. The exemplary method may also include operations of block 1250, where the RAN node may send at least a portion of the received one or more MHI reports to the second RAN node.

In some embodiments, when the first network is a PN, one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least part of the first MHI but does not include the second MHI; ● a single MHI report that includes the first MHI and the second MHI; or ● a first MHI report that includes the first MHI and a second MHI report that includes the second MHI.

In some of these embodiments, at least a portion of the first MHI included in the single MHI report corresponds to one of: ● all of the first MHI collected for all of the visited PN cells; or ● only the first MHI collected for the visited PN cells associated with the first network.

In some embodiments, when the first network is an NPN, one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least a portion of the second MHI but does not include the first MHI; ● a single MHI report that includes the first MHI and the second MHI; or ● a first MHI report that includes the first MHI and a second MHI report that includes at least a portion of the second MHI.

In some of these embodiments, at least a portion of the second MHI included in the single MHI report or the second MHI report corresponds to one of: ● all second MHIs collected for all visited NPN cells; or ● second MHIs collected only for visited NPN cells associated with the first network.

In some embodiments, for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, each MHI report entry corresponds to a visited cell and indicates one of the following for the visited cell: ● Whether the visited cell is associated with a PN or an NPN (e.g., as shown in FIGS. 7-8 ); or ● Whether information reported for the visited cell should be disclosed to other networks (e.g., as shown in FIG. 9 ).

In some of these embodiments, each MHI report entry corresponding to a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell.

In some embodiments, each MHI reporting entry corresponding to a visited NPN cell includes a first indication of a duration that the UE spent in the visited NPN cell and a second indication that the visited NPN cell is associated with one of: an NPN; or a network and/or a network type that cannot be disclosed.

In some embodiments, the exemplary method may also include the operation of block 1220, wherein the RAN node may send an information request for MHI for PN records and MHI for NPN records to the UE. In this case, receiving one or more MHI reports in block 1230 is in response to the information request. In various embodiments, the information request includes one of the following: ● A single indication of a request for MHI for PN records and MHI for NPN records; or ● A first indication of a request for MHI for PN records and a second indication of a request for MHI for NPN records.

In some embodiments, the exemplary method may also include the operation of block 1210, wherein the RAN node may send a configuration for recording and reporting MHI to the UE. In this case, the content of the received one or more MHI reports is based on the configuration.

In some embodiments, the RAN node and the second RAN node are configured to dually connect to the UE. In other embodiments, a cell served by the second RAN node is a target cell for a UE mobility procedure (e.g., handover), and at least a portion of the received one or more MHI reports are sent to the second RAN node with the mobility procedure (e.g., in a handover request).

In some embodiments, the one or more MHI reports include a first MHI report containing at least a portion of the first MHI and a second MHI report containing at least a portion of the second MHI. In these embodiments, the first and second MHI reports are sent to the second RAN node as one of: separate fields of a single IE in a message; or separate IEs in a message. Various examples of such configurations are described above in the context of text of the 3GPP specification.

In addition, FIG. 13 illustrates another exemplary method (e.g., procedure) for a UE configured to operate in a public network and a non-public network according to various embodiments of the present invention. For example, the exemplary method shown in FIG. 13 may be performed by a UE (e.g., a wireless device) described with reference to other figures herein.

The exemplary method includes operations of block 1320, wherein the UE may record first mobile history information (MHI) associated with one or more public networks and/or visited cells in the one or more public networks. The exemplary method also includes operations of block 1330, wherein the UE may record second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks. The exemplary method may include operations of block 1350, wherein upon subsequently connecting to a first network, the UE may send one or more MHI reports to the first network, the one or more MHI reports including one or more of: at least a portion of the recorded first MHI; and at least a portion of the recorded second MHI.

In some embodiments, the recorded second MHI includes an indication of a duration that the UE spent outside a public network and one of: an indication of the duration spent in a non-public network; or an indication of the duration spent in a network whose type and/or identity cannot be disclosed. One example of these embodiments is the proposed 3GPP specification discussed above, wherein, after entering an NR PN, the UE sets the following fields of an entry in the variable VarMobilityHistoryReport when previously using another network type (e.g., SNPN): ● Field timeSpent as the time spent outside the current network type (i.e., public network); and ● Field NetworkType as the selected network type (e.g., non-public network) to which the UE was connected before entering the current network type (i.e., public network) (in RRC_CONNECTED, RRC_IDLE, or RRC_INACTIVE).

In some of these embodiments, when the recorded second MHI for a non-public network includes an indication of the duration spent in a non-public network, the recorded second MHI also includes an identification code of the non-public network.

In some embodiments, the recorded first MHI includes an indication of a duration that the UE spent outside a non-public network and one of: an indication of the duration spent in a public network; or an indication of the duration spent in a network whose type and/or identity cannot be disclosed. An example of these embodiments is the proposed 3GPP specification discussed above, wherein, after entering NR SNPN, the UE sets the following fields of an entry in the variable VarMobilityHistoryReport when previously using another network type (e.g., PN): ● Field timeSpent as the time spent outside the current network type (i.e., non-public network); and ● Field NetworkType as the selected network type (e.g., public network) to which the UE was connected before entering the current network type (i.e., non-public network) (in RRC_CONNECTED, RRC_IDLE, or RRC_INACTIVE).

In some embodiments, for each visited cell in a non-public network, the recorded second MHI includes an indication of a duration the UE spent in the visited cell and one of: an indication that the visited cell is part of a non-public network; or an indication that the visited cell is part of a network whose type and/or identity cannot be disclosed.

In some embodiments, one or more MHI reports are configured according to one of the following: ● a single MHI report that includes at least a portion of the first MHI but does not include the second MHI; ● a single MHI report that includes at least a portion of the second MHI but does not include the first MHI; ● a single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI; or ● a first MHI report that includes at least a portion of the first MHI and a second MHI report that includes at least a portion of the second MHI.

In some of these embodiments, when the first network is a public network, at least a portion of the first MHI included in the single MHI report (i.e., in the first option above) corresponds to one of the following: ● All first MHIs recorded for all visited public networks and/or all visited cells in the public network; or ● Only the first MHI recorded for the first network and/or the visited cells in the first network.

In other of these embodiments, when the first network is a non-public network, at least a portion of the second MHI included in the single MHI report (i.e., in the second and third options above) or the second MHI report (i.e., in the fourth option above) corresponds to one of the following: ● All second MHIs recorded for all visited non-public networks and/or all visited cells in the non-public network; or ● Only the second MHI recorded for the first network and/or the visited cells in the first network.

In some such embodiments, the exemplary method may also include the operation of block 1360, wherein after sending a single MHI report that includes at least a portion of the second MHI but does not include the first MHI, the UE may discard (e.g., delete or otherwise make unavailable) the first MHI in response to the earlier of the following events: ● connecting to a second network that is a public network and sending the first MHI to the second network; or ● expiration of a time limit without sending the first MHI to a public network.

In some such embodiments, for any single MHI report that includes at least a portion of a first MHI and at least a portion of a second MHI, at least one entry in the MHI report is associated with a respective at least one visited cell. Each of the at least one entry indicates one of the following for the associated visited cell: ● Whether the visited cell is associated with a public network or a non-public network; or ● Whether information reported for the visited cell should be disclosed to other networks.

In some variations of these embodiments, each entry associated with a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell.

In some embodiments, the first MHI and the second MHI are recorded in separate UE variables. In other embodiments, the first MHI and the second MHI are recorded in a single UE variable.

In some embodiments, the exemplary method may also include the operations of block 1340, wherein after subsequently connecting to the first network, the UE may receive from the first network an information request for MHI recorded for public networks and MHI recorded for non-public networks. In this case, sending one or more MHI reports in block 1350 is in response to the information request. In some of these embodiments, the information request includes a single indication of a request for MHI recorded for public networks and MHI recorded for non-public networks. In others of these embodiments, the information request includes a first indication of a request for MHI recorded for public networks and a second indication of a request for MHI recorded for non-public networks.

In some embodiments, the exemplary method may also include the operation of block 1340, wherein the UE may receive a configuration for recording and reporting MHI from the first network or from a second network. In this case, recording the first and second MHIs in blocks 1320 to 1330 and sending one or more MHI reports in block 1350 are based on the configuration.

In addition, FIG. 14 illustrates another exemplary method (e.g., procedure) for a RAN node configured to operate in a first network according to various embodiments of the present invention. For example, the exemplary method shown in FIG. 14 may be performed by a RAN node (e.g., base station, eNB, gNB, ng-eNB, etc.), as described elsewhere herein. Also, the exemplary method shown in FIG. 14 may be used in conjunction with the exemplary method shown in FIG. 13.

An exemplary method includes the operations of block 1430, wherein a RAN node may receive one or more MHI reports from a UE, the one or more MHI reports including one or more of the following recorded by the UE: ● A first MHI associated with one or more visited public networks and/or visited cells in one or more public networks, and ● A second MHI associated with one or more non-public networks and/or visited cells in one or more non-public networks.

The exemplary method also includes the operations of blocks 1440 to 1450, wherein the RAN node may identify a second RAN node based on the received one or more MHI reports and send at least a portion of the received one or more MHI reports to the second RAN node.

In various embodiments, the first and second MHIs may have any of the same content, form and/or structure as the corresponding first and second MHIs recorded by a UE, as described above with respect to the UE embodiment shown in FIG. 13. Likewise, the one or more MHI reports may have any of the same content, form and/or structure as the corresponding one or more MHI reports described above with respect to the UE embodiment shown in FIG. 13. In other words, the one or more MHI reports received by the RAN node correspond to the one or more MHI reports sent by the UE.

In some embodiments, the first and second MHI reports are sent to the second RAN node as one of: separate fields of a single information element (IE) in a message; or separate IEs in the message.

In some embodiments, the exemplary method also includes the operation of block 1420, wherein the RAN node may send an information request for MHI recorded for public networks and MHI recorded for non-public networks to the UE. In this case, receiving one or more MHI reports in block 1430 is in response to the information request. In some of these embodiments, the information request includes a single indication of a request for MHI recorded for public networks and MHI recorded for non-public networks. In others of these embodiments, the information request includes a first indication of a request for MHI recorded for public networks and a second indication of a request for MHI recorded for non-public networks.

In some embodiments, the exemplary method also includes the operation of block 1410, wherein the RAN node may send a configuration for recording and reporting MHI to the UE. The content of one or more MHI reports is based on the configuration.

In some embodiments, the RAN node and the second RAN node are configured to dually connect to the UE. In other embodiments, a cell served by the second RAN node is a target cell for a UE mobility procedure, and at least a portion of the received one or more MHI reports is sent to the second RAN node with the mobility procedure. In some embodiments, the second RAN node serves one or more of the cells identified in the one or more MHI reports.

Although various embodiments are described above in terms of methods, techniques and/or procedures, a person of ordinary skill will readily understand that such methods, techniques and/or procedures may be embodied in various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, computer program products, etc.

15 shows an example of a communication system 1500 according to some embodiments. In this example, the communication system 1500 includes a telecommunications network 1502, which includes an access network 1504 (e.g., RAN) and a core network 1506, which includes one or more core network nodes 1508. The access network 1504 includes one or more access network nodes, such as network nodes 1510a-1510b (one or more of which may be generally referred to as network nodes 1510) or any other similar 3GPP access nodes or non-3GPP access points. Network node 1510 facilitates direct or indirect connectivity of UEs, such as by connecting UEs 1512a-1512d (one or more of which may be generally referred to as UE 1512) to core network 1506 via one or more wireless connections.

Examples of wireless communication via a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. In addition, in various embodiments, the communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that facilitate or participate in the communication of data and/or signals via a wired or wireless connection. The communication system 1500 may include and/or interface with any type of communication, telecommunication, data, cellular, wireless network, and/or other similar types of systems.

UE 1512 may be any of a variety of communication devices, including wireless devices that are configured, configured, and/or operable to wirelessly communicate with network node 1510 and other communication devices. Similarly, network node 1510 is configured, capable, configured, and/or operable to communicate directly or indirectly with UE 1512 and/or with other network nodes or devices in telecommunication network 1502 to implement and/or provide network access (such as wireless network access) and/or perform other functions (such as management in telecommunication network 1502).

In the depicted example, core network 1506 connects network node 1510 to one or more hosts, such as host 1516. Such connections may be direct, or indirectly via one or more intermediate networks or devices. In other examples, the network node may be directly coupled to the host. Core network 1506 includes one or more core network nodes (e.g., 1508) structured by hardware and software components. The features of these components may be substantially similar to those described with respect to UEs, network nodes, and/or hosts, so that their descriptions generally apply to the corresponding components of core network node 1508. The example core network node includes one or more functions of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier dehiding function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF) and/or a user plane function (UPF).

Host 1516 may be under the ownership or control of a service provider other than an operator or provider of access network 1504 and/or telecommunications network 1502, and may be operated by or on behalf of the service provider. Host 1516 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio/video content, data collection services (such as capturing and compiling data under various ambient conditions detected by multiple UEs), analysis functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and monitoring center, or any other such functions performed by a server.

In summary, the communication system 1500 of Figure 15 implements connections between UEs, network nodes, and hosts. In this sense, the communication system may be configured to operate according to predefined rules or procedures, such as a particular standard, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any suitable future generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and/or any other appropriate wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

In some examples, the telecommunication network 1502 is a cellular network that implements one of the 3GPP standardized features. Therefore, the telecommunication network 1502 can support network slicing to provide different logical networks to different devices connected to the telecommunication network 1502. For example, the telecommunication network 1502 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, while providing enhanced mobile broadband (eMBB) services to other UEs, and/or providing massive machine type communication (mMTC)/massive IoT services to yet further UEs.

In some examples, UE 1512 is configured to transmit and/or receive information without direct human interaction. For example, a UE may be designed to transmit information to access network 1504 on a predetermined schedule when triggered by an internal or external event or in response to a request from access network 1504. In addition, a UE may be configured to operate in single RAT or multi-RAT or multi-standard mode. For example, a UE may operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

In an example, hub 1514 communicates with access network 1504 to facilitate indirect communication between one or more UEs (e.g., 1512c and/or 1512d) and a network node (e.g., network node 1510b). In some examples, hub 1514 can be a controller, router, content source and analyzer, or any other communication device described herein with respect to a UE. For example, hub 1514 can be a broadband router that allows a UE to access core network 1506. As another example, hub 1514 can be a controller that sends commands or instructions to one or more actuators in a UE. Commands or instructions can be received from a UE, network node 1510, or by executable code, scripts, programs, or other instructions in hub 1514. As another example, the hub 1514 can be a data collector that acts as a temporary storage for UE data, and in some embodiments, can perform analysis or other processing of the data. As another example, the hub 1514 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 1514 can capture VR assets, video, audio, or other media or data related to sensory information via a network node, and then the hub 1514 provides it directly to the UE after performing local processing and/or after adding additional local content. In yet another example, the hub 1514 acts as a proxy server or coordinator for the UE, particularly in the case where one or more of the UEs are low-energy IoT devices.

Hub 1514 may have a constant/permanent or intermittent connection to network node 1510b. Hub 1514 may also allow a different communication scheme and/or schedule between hub 1514 and UE (e.g., 1512c and/or 1512d) and between hub 1514 and core network 1506. In other examples, hub 1514 is connected to core network 1506 and/or one or more UEs via a wired connection. In addition, hub 1514 may be configured to connect to an M2M service provider via access network 1504 and/or to another UE via a direct connection. In some cases, UE may establish a wireless connection with network node 1510 while still being connected via hub 1514 via a wired or wireless connection. In some embodiments, hub 1514 may be a dedicated hub, i.e., a hub whose primary function is to route communications from UE to network node 1510b/from network node 1510b to UE. In other embodiments, hub 1514 may be a non-dedicated hub, i.e., a device that is operable to route communications between UE and network node 1510b, but is additionally operable as a communication origin and/or endpoint for certain data channels.

FIG. 16 shows a UE 1600 according to some embodiments. Examples of a UE include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a game console or device, a music storage device, a playback device, a wearable terminal device, a wireless terminal, a mobile station, a tablet computer, a laptop, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer terminal equipment (CPE), a vehicle mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by 3GPP, including a narrowband Internet of Things (NB-IoT) UE, a machine type communication (MTC) UE and/or an enhanced MTC (eMTC) UE.

A UE may support device-to-device (D2D) communications, for example by implementing a 3GPP standard for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the associated device. Alternatively, a UE may represent a device (e.g., a smart sprinkler controller) that is intended to be sold to or operated by a human user but which may not be, or may not initially be, associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended to be sold to or operated by an end user but which may be associated with or operated for the benefit of a user.

UE 1600 includes processing circuitry 1602, which is operably coupled to input/output interface 1606, power supply 1608, memory 1610, communication interface 1612, and possible other components not specifically shown via bus 1604. Some UEs may utilize all or a subset of the components shown in FIG. 16. The level of integration between components may vary from UE to UE. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

Processing circuit 1602 is configured to process instructions and data, and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory 1610. Processing circuit 1602 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general purpose processors such as a microprocessor or digital signal processor (DSP) together with appropriate software; or any combination of the above. For example, processing circuit 1602 may include multiple central processing units (CPUs).

In an example, the input/output interface 1606 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smart card, another output device, or any combination thereof. An input device can allow a user to capture information into the UE 1600. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, and the like. A presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. For example, a sensor may be an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, or any combination thereof. An output device may use the same type of interface port as an input device. For example, a universal serial bus (USB) port may be used to provide an input device and an output device.

In some embodiments, the power supply 1608 is structured as a battery or battery pack. Other types of power supplies may be used, such as an external power source (e.g., an electrical outlet), photovoltaic devices, or batteries. The power supply 1608 may further include power circuits for delivering power from the power supply 1608 itself and/or an external power source to various parts of the UE 1600 via input circuits or an interface (such as a power cable). The delivered power may be used, for example, to charge the power supply 1608. The power circuits may perform any formatting, conversion, or other modifications to the power from the power supply 1608 to make the power suitable for the respective components of the UE 1600 to which the power is supplied.

The memory 1610 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), a disk, an optical disk, a hard disk, a removable cartridge, a flash drive, etc. In one example, the memory 1610 includes one or more applications 1614, such as an operating system, a web browser application, a widget, a gadget engine, or other applications and corresponding data 1616. The memory 1610 may store any of a variety of operating systems or a combination of operating systems for use by the UE 1600.

The memory 1610 can be configured to include a number of physical drive units, such as a redundant array of independent disks (RAID), a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, smart card memory (such as a tamper-resistant module in the form of a universal integrated circuit card (UICC), including one or more user identification modules (SIMs), such as a USIM and/or ISIM), other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". The memory 1610 may allow the UE 1600 to access instructions, applications, and the like stored on a temporary or non-temporary memory medium to download data or upload data. An article of manufacture (such as an article of manufacture utilizing a communication system) may be tangibly embodied as or in the memory 1610, which may be or include a device-readable storage medium.

The processing circuit 1602 may be configured to communicate with an access network or other network using the communication interface 1612. The communication interface 1612 may include one or more communication subsystems and may include or be communicatively coupled to the antenna 1622. The communication interface 1612 may include one or more transceivers for communicating, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1618 and/or a receiver 1620 suitable for providing network communications (e.g., optical, electrical, frequency distribution, etc.). In addition, the transmitter 1618 and/or the receiver 1620 may be coupled to one or more antennas (e.g., 1622) and may share circuit components, software, or firmware, or alternatively be implemented separately.

In the illustrated embodiment, the communication functionality of the communication interface 1612 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth), near field communication, location-based communication (such as using a global positioning system (GPS) to determine a location), another similar communication functionality, or any combination thereof. Communication may be implemented according to one or more communication protocols and/or standards, such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, new radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/Internet protocol (TCP/IP), synchronous optical network connection (SONET), asynchronous transfer mode (ATM), QUIC, hypertext transfer protocol (HTTP), etc.

Regardless of the type of sensor, a UE may provide an output of data captured by its sensor via a wireless connection to a network node through its communication interface 1612. Data captured by a UE's sensor may be passed through another UE via a wireless connection to a network node. The output may be periodic (e.g., once every 15 minutes if it reports sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a trigger event (e.g., sending an alarm when moisture is detected), in response to a request (e.g., a user initiated request), or continuously streamed (e.g., a live video feed of a patient).

As another example, a UE includes an actuator, a motor, or a switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch may change. For example, the UE may include a motor that adjusts a control surface or rotor of a flying drone based on the received input or adjusts a robotic arm performing a medical procedure based on the received input.

When in the form of an Internet of Things (IoT) device, a UE may be a device used in one or more application areas including, but not limited to, urban wearable technology, expanding industrial applications, and healthcare. Non-limiting examples of such an IoT device are as or embedded in one of the following: a connected refrigerator or freezer, a TV, a connected lighting device, a meter, a robotic vacuum cleaner, a voice-controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electronic door lock, a connected doorbell, an air conditioning system (such as a heat pump), an autonomous vehicle, a surveillance system, A weather monitoring device, a parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head mounted display for augmented reality (AR) or virtual reality (VR), a wearable device for haptic augmentation or sensory enhancement, a sprinkler, an animal or object tracking device, a sensor for monitoring a plant or animal, an industrial robot, an unmanned aerial vehicle (UAV), and any kind of medical device, such as a heart rate monitor or a remote controlled surgical robot. In addition to the other components as described with respect to the UE 1600 shown in FIG. 16 , a UE in the form of an IoT device also includes circuitry and/or software dependent on the intended application of the IoT device.

As yet another specific example, in an IoT case, a UE may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another UE and/or a network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in a 3GPP context. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other cases, a UE may represent a vehicle, such as a car, a bus, a truck, a ship, and an airplane, or other equipment capable of monitoring and/or reporting its operating status or other functions associated with its operation.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE may be a drone or integrated into a drone, and provide the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and/or second UE may also include more than one of the functionalities described above. For example, a UE may include a sensor and an actuator, and handle data communications for both the speed sensor and the actuator.

17 shows a network node 1700 according to some embodiments. Examples of network nodes include, but are not limited to, access points (e.g., radio access points) and base stations (e.g., radio base stations, Node Bs, eNBs, and gNBs).

Base stations can be classified based on the amount of coverage they provide (or in other words, their transmit power level) and therefore, depending on the amount of coverage provided, can be called a femto base station, a pico base station, a micro base station, or a macro base station. A base station can be a relay node that controls a repeater or a relay provider node. A network node can also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and/or a remote radio unit (RRU), sometimes called a remote radio head (RRH). These remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Portions of a distributed radio base station can also be called nodes in a distributed antenna system (DAS).

Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment (such as MSR BS), network controllers (such as radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., Evolved Served Mobile Location Center (E-SMLC)) and/or minimized driven testing (MDT).

The network node 1700 includes a processing circuit 1702, a memory 1704, a communication interface 1706, and a power supply 1708. The network node 1700 may be composed of multiple physically separate components (e.g., a NodeB component and an RNC component or a BTS component and a BSC component, etc.), each of which may have its own respective components. In some cases where the network node 1700 includes multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In this case, each unique NodeB and RNC pair may be considered a single separate network node in some instances. In some embodiments, the network node 1700 may be configured to support multiple radio access technologies (RATs). In these embodiments, some components may be duplicated (e.g., separate memory 1704 for different RATs) and some components may be reused (e.g., a common antenna 1710 may be shared by different RATs). The network node 1700 may also include multiple sets of the various components depicted for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies) integrated into the network node 1700. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node 1700.

The processing circuit 1702 may include one or more of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic that can operate alone or in conjunction with other network node 1700 components (such as memory 1704) to provide network node 1700 functionality.

In some embodiments, processing circuit 1702 includes a system on a chip (SOC). In some embodiments, processing circuit 1702 includes radio frequency (RF) transceiver circuit 1712 and/or baseband processing circuit 1714. In some embodiments, RF transceiver circuit 1712 and/or baseband processing circuit 1714 may be on separate chips (or chipsets), boards, or units (such as a radio unit and a digital unit). In alternative embodiments, part or all of RF transceiver circuit 1712 and baseband processing circuit 1714 may be on the same chip or chipset, board, or unit.

Memory 1704 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard drive), removable storage media (e.g., a flash drive, a compact disk (CD), or a digital video disc (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory device that stores information, data, and/or instructions that may be used by processing circuit 1702. Memory 1704 may store any suitable instructions, data, or information, including a computer program, software, an application (including one or more of logic, rules, code, tables), and/or other instructions that can be executed by processing circuit 1702 and utilized by network node 1700 (collectively represented as computer program 1704a, which may be in the form of a computer program product). Memory 1704 may be used to store any calculations performed by processing circuit 1702 and/or any data received via communication interface 1706. In some embodiments, processing circuit 1702 and memory 1704 are integrated.

The communication interface 1706 is used for wired or wireless communication of signaling and/or data between a network node, access network and/or UE. As shown, the communication interface 1706 includes (several) ports/(several) terminals 1716 to send data to a network and receive data from the network, for example, via a wired connection. The communication interface 1706 also includes a radio front-end circuit 1718, which can be coupled to the antenna 1710 or is a part of the antenna 1710 in some embodiments. The radio front-end circuit 1718 includes a filter 1720 and an amplifier 1722. The radio front-end circuit 1718 can be connected to the antenna 1710 and the processing circuit 1702. The radio front end circuit 1718 may be configured to condition the signals passed between the antenna 1710 and the processing circuit 1702. The radio front end circuit 1718 may receive digital data to be sent to other network nodes or UEs via a wireless connection. The radio front end circuit 1718 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of a filter 1720 and/or an amplifier 1722. The radio signal may then be transmitted via the antenna 1710. Similarly, when receiving data, the antenna 1710 may collect radio signals, which are then converted into digital data by the radio front end circuit 1718. The digital data may be passed to the processing circuit 1702. In other embodiments, the communication interface may include different components and/or different combinations of components.

In some alternative embodiments, the network node 1700 does not include a separate radio front end circuit 1718, instead the processing circuit 1702 includes the radio front end circuit and is connected to the antenna 1710. Similarly, in some embodiments, all or some of the RF transceiver circuit 1712 is part of the communication interface 1706. In still other embodiments, the communication interface 1706 includes one or more ports or terminals 1716, the radio front end circuit 1718, and the RF transceiver circuit 1712 as part of a radio unit (not shown), and the communication interface 1706 communicates with the baseband processing circuit 1714, which is part of a digital unit (not shown).

Antenna 1710 may include one or more antennas or antenna arrays configured to send and/or receive wireless signals. Antenna 1710 may be coupled to radio front end circuitry 1718 and may be any type of antenna capable of wirelessly transmitting and receiving data and/or signals. In some embodiments, antenna 1710 may be separate from network node 1700 and may be connected to network node 1700 via an interface or port.

Antenna 1710, communication interface 1706 and/or processing circuit 1702 may be configured to perform any receiving operation and/or certain acquisition operations described herein as being performed by a network node. Any information, data and/or signal may be received from a UE, another network node and/or any other network device. Similarly, antenna 1710, communication interface 1706 and/or processing circuit 1702 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data and/or signal may be transmitted to a UE, another network node and/or any other network device.

The power supply 1708 provides power to the various components of the network node 1700 in a form suitable for the respective components (e.g., at a voltage and current level required by the respective components). The power supply 1708 may further include or be coupled to power management circuitry to supply power to the components of the network node 1700 to perform the functionality described herein. For example, the network node 1700 may be connected to an external power source (e.g., the electrical grid, an electrical outlet) via an input circuit or interface (such as a cable), whereby the external power source supplies power to the power circuitry of the power supply 1708. As a further example, the power supply 1708 may include a power source in the form of a battery or battery pack connected to the power circuitry or integrated therein. The battery may provide backup power if the external power source fails.

Embodiments of network node 1700 may include additional components beyond those shown in FIG. 17 that are used to provide certain aspects of the functionality of the network node, including any of the functionality described herein and/or any functionality required to support the subject matter described herein. For example, network node 1700 may include user interface devices to allow information to be input to network node 1700 and to allow information to be output from network node 1700. This may allow a user to perform diagnostic, maintenance, repair, and other management functions of network node 1700.

FIG. 18 is a block diagram of a host 1800 according to various aspects described herein, which may be an embodiment of the host 1318 of FIG. 15 . As used herein, the host 1800 may be or include various combinations of hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources in a server farm. The host 1800 may provide one or more services to one or more UEs.

The host 1800 includes a processing circuit 1802, which is operably coupled to an input/output interface 1806, a network interface 1808, a power supply 1810, and a memory 1812 via a bus 1804. Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to the devices of the previous figures (such as Figures 16 and 17), so that their descriptions are generally applicable to the corresponding components of the host 1800.

Memory 1812 may include one or more computer programs, including one or more host applications 1814, and data 1816, which may include user data, such as data generated by a UE for host 1800 or data generated by host 1800 for a UE. An embodiment of host 1800 may utilize only a subset or all of the components shown. The host application 1814 can be implemented in a container-based architecture and can provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). The host application 1814 can also provide user authentication and authorization checks, and can periodically report health, routing, and content availability to a central node (such as a device in a core network or on the edge). Therefore, the host 1800 can select and/or instruct a different host for a UE's cloud service. The host application 1814 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), HTTP Dynamic Adaptive Streaming (MPEG-DASH), etc.

FIG. 19 is a block diagram illustrating a virtualized environment 1900 in which functionality implemented by some embodiments may be virtualized. In the present context, virtualization means generating a virtualized version of a device or component, which may include virtualized hardware platforms, storage devices, and network connection resources. As used herein, virtualization may apply to any device or component thereof described herein, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1900 hosted by one or more hardware nodes, such as a hardware computing device operating as a network node, UE, core network node, or host. In addition, in embodiments where a virtual node does not require a radio connection (e.g., a core network node or host), the node may be fully virtualized.

Applications 1902 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) run in virtual environment 1900 to implement some features, functions and/or benefits of some embodiments disclosed herein.

Hardware 1904 includes: processing circuitry; memory storing software and/or instructions (collectively represented as computer program 1904a, which may be in the form of a computer program product) that may be executed by the hardware processing circuitry; and/or other hardware devices as described herein, such as a network interface, input/output interface, etc. The software may be executed by the processing circuitry to instantiate one or more virtualization layers 1906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1908a-1908b (one or more of which may be generally referred to as VMs 1908), and/or perform any functions, features, and/or benefits described with respect to some of the embodiments described herein. Virtualization layer 1906 may present a virtual operating platform to VM 1908 that appears to be network-connected hardware.

VM 1908 includes virtual processing, virtual memory, virtual network links or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 1906. Different embodiments of an instance of a virtual appliance 1902 may be implemented on one or more of VMs 1908, and the implementations may be performed in different ways. Virtualization of hardware is referred to in some contexts as network function virtualization (NFV). NFV can be used to consolidate many network equipment types onto industry standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and user end devices.

In the context of NFV, each VM 1908 may be a software implementation of a physical machine that runs programs just as they would run on a physical, non-virtualized machine. Each VM 1908 and the portion of hardware 1904 on which it runs, whether hardware dedicated to the VM and/or hardware shared by the VM with other VMs, form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for a specific network function running in one or more VMs 1908 hosted on top of hardware 1904 and corresponds to an application 1902.

Hardware 1904 may be implemented in a standalone network node having general or specific components. Hardware 1904 may implement some functions via virtualization. Alternatively, hardware 1904 may be part of a larger hardware cluster (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1910, which oversees, among other things, life cycle management of applications 1902. In some embodiments, hardware 1904 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio unit may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with virtual components to provide a virtual node (such as a radio access node or a base station) with radio capabilities. In some embodiments, some signaling may be provided using a control system 1912, which may alternatively be used for communication between hardware nodes and radio units.

FIG20 shows a communication diagram of a host 2002 communicating with a UE 2006 via a portion of a wireless connection via a network node 2004 according to some embodiments. According to various embodiments, example implementations of the UE (such as a UE 1512a of FIG15 and/or UE 1600 of FIG16), network nodes (such as network nodes 1510a of FIG15 and/or network nodes 1700 of FIG17), and hosts (such as host 1518 of FIG15 and/or host 1800 of FIG18) discussed in the preceding paragraphs will now be described with reference to FIG20.

As with host 1800, embodiments of host 2002 include hardware, such as a communication interface, processing circuitry, and memory. Host 2002 also includes software stored in or accessible by host 2002 and executable by the processing circuitry. The software includes a host application that is operable to provide a service to a remote user, such as UE 2006 connected via an over-the-top (OTT) connection 2050 extending between UE 2006 and host 2002. In providing the service to the remote user, a host application may provide user data, which is transmitted using OTT connection 2050.

Network node 2004 includes hardware that enables it to communicate with host 2002 and UE 2006. Connection 2060 can be direct or through a core network (such as core network 1506 of Figure 15) and/or one or more other intermediate networks, such as one or more public, private or hosted networks. For example, an intermediate network can be a backbone network or the Internet.

UE 2006 includes hardware and software that is stored in or accessible by UE 2006 and executed by processing circuitry of the UE. The software includes a client application, such as a web browser or operator specific "app", that is operable to provide a service to a human or non-human user via UE 2006 with the support of host 2002. In host 2002, an executing host application can communicate with the executing client application via an OTT connection 2050 terminating at UE 2006 and host 2002. In providing the service to the user, the client application of the UE can receive request data from the host application of the host and provide user data in response to the request data. The OTT connection 2050 can transmit both request data and user data. The client application of the UE can interact with the user to generate user data that it provides to the host application through the OTT connection 2050.

The OTT connection 2050 may extend via a connection 2060 between the host 2002 and the network node 2004 and via a wireless connection 2070 between the network node 2004 and the UE 2006 to provide connectivity between the host 2002 and the UE 2006. The connection 2060 and the wireless connection 2070 (through which the OTT connection 2050 may be provided) have been drawn abstractly to illustrate communications between the host 2002 and the UE 2006 via the network node 2004 without explicitly mentioning any intermediary devices and the precise routing of messages through such devices.

As an example of transmitting data via OTT connection 2050, in step 2008, host 2002 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user with which UE 2006 interacts. In other embodiments, the user data is associated with a UE 2006 that shares data with host 2002 without explicit human interaction. In step 210, host 2002 initiates a transmission of the user data toward UE 2006. Host 2002 can initiate the transmission in response to a request transmitted by UE 2006. The request can result from human interaction with UE 2006 or from operation of a client application executing on UE 2006. According to the teachings of the embodiments described throughout the present invention, the transmission may pass through the network node 2004. Therefore, according to the teachings of the embodiments described throughout the present invention, in step 2012, the network node 2004 transmits the user data carried in the transmission initiated by the host 2002 to the UE 2006. In step 2014, the UE 2006 receives the user data carried in the transmission, which may be executed by a client application executing on the UE 2006 that is associated with the host application executed by the host 2002.

In some examples, UE 2006 executes a client application that provides user data to host 2002. The user data may be provided in response to or in response to data received from host 2002. Therefore, in step 2016, UE 2006 may provide the user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of UE 2006. Regardless of how the user data is provided, UE 2006 initiates transmission of the user data toward host 2002 via network node 2004 in step 2018. In step 2020, network node 2004 receives user data from UE 2006 and initiates transmission of the received user data toward host 2002 in accordance with the teachings of the embodiments described throughout the present invention. In step 2022, host 2002 receives the user data carried in the transmission initiated by UE 2006.

One or more of the various embodiments improves the performance of OTT services provided to UE 2006 using OTT connection 2050 (with wireless connection 2070 forming the final segment). More specifically, embodiments described herein may enable a network (e.g., PLMN) to determine, based on the UE MHI, whether a UE is not connected to a network cell because it is not within the coverage of the network or because it is connected to an NPN but is still within the coverage. In addition, embodiments may prevent a UE from sending sensitive, confidential and/or proprietary information about a visited NPN to a PLMN or another NPN. In embodiments where the UE provides this information, explicit marking of the NPN relationship may prevent a PLMN from sharing the information with other PLMNs and/or NPNs. In this way, embodiments may protect the privacy and security of NPNs and their users. By improving the security of the network in this way, embodiments increase the value of OTT services delivered to end users and service providers over the improved network.

In one example case, factory status information may be collected and analyzed by host 2002. As another example, host 2002 may process audio and video data that may have been captured from a UE for use in creating a map. As another example, host 2002 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, host 2002 may store surveillance video uploaded by a UE. As another example, host 2002 may store or control access to media content that may be broadcast, multicast, or unicast to UEs, such as video, audio, VR, or AR. As other examples, 2002 may be used for energy pricing, remote control of non-time critical electrical loads to balance generation demand, location services, presentation services (such as compiling charts based on data collected from remote devices), or any other function of collecting, capturing, storing, analyzing and/or transmitting data.

In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors improved by one or more embodiments. There may further be an optional network functionality for reconfiguring the OTT connection 2050 between the host 2002 and the UE 2006 in response to changes in the measurement results. The measurement procedure and/or network functionality for reconfiguring the OTT connection may be implemented in the software and hardware of the host 2002 and/or the UE 2006. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 2050 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above or supplying values of other physical quantities that the software can use to calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 2050 may include message formats, retransmission settings, optimal routing, etc.; reconfiguration does not require direct changes to the operation of the network node 2004. Such procedures and functionality may be known and practiced in the art. In certain embodiments, measurement may involve dedicated UE signaling that facilitates host 2002 measurement of throughput, propagation time, latency, and the like. Measurement may be implemented where software causes messages (specifically, empty or "dummy" messages) to be transmitted using the OTT connection 2050 while monitoring propagation time, errors, etc.

The foregoing merely illustrates the principles of the invention. In light of the teachings herein, various modifications and alterations to the described embodiments will be apparent to those skilled in the art. Thus, it will be appreciated that those skilled in the art will be able to design a number of systems, configurations, and programs that, although not expressly shown or described herein, embody the principles of the invention and are therefore within the spirit and scope of the invention. The various embodiments may be used together and interchangeably, as will be understood by those of ordinary skill in the art.

As used herein, the term unit may have the known meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuits, devices, modules, processors, memories, logical solid-state and/or discrete devices, computer programs or instructions for implementing respective tasks, procedures, calculations, output and/or display functions, etc. (such as the functions described herein).

Any suitable steps, methods, features, functions, or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a number of such functional units. Such functional units may be implemented by processing circuits (which may include one or more microprocessors or microcontrollers) and other digital hardware (which may include digital signal processors (DSPs), application-specific digital logic, and the like). The processing circuits may be configured to execute program code stored in a memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and/or data communication protocols and instructions for implementing one or more of the techniques described herein. In some implementation schemes, the processing circuit can be used to cause each functional unit to execute the corresponding function according to one or more embodiments of the present invention.

As described herein, a device and/or apparatus may be represented by a semiconductor chip, a chipset or a (hardware) module comprising such a chip or chipset; however, this does not exclude the possibility that a functionality of a device or apparatus is implemented as a software module (such as a computer program or a computer program product comprising executable software code portions for execution or operation on a processor) rather than hardware. Furthermore, the functionality of a device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and/or apparatus, whether or not they cooperate with each other functionally or independently of each other. Furthermore, devices and apparatus may be implemented in a distributed manner throughout a system, as long as the functionality of the device or apparatus is retained. These and similar principles are considered to be known to those skilled in the art.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by a person of ordinary skill in the art to which the present invention belongs. It will be further understood that the terms used herein should be interpreted as having a meaning consistent with their meanings in the context of this specification and related art and will not be interpreted in an idealized or overly formal sense unless explicitly defined in this document.

In addition, certain terms used in the present invention (including the specification and drawings) may be used synonymously in certain instances (e.g., "data" and "information"). It should be understood that although these terms (and/or other terms that may be synonymous with each other) may be used synonymously herein, there may be instances in which these words are not intended to be used synonymously.

Embodiments of the techniques and devices described herein also include (but are not limited to) the following enumerated examples: A1.   A method for a user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN), the method comprising: When visiting one or more cells in one or more PNs, recording first mobile history information (MHI) associated with the visited PN cells; When visiting one or more cells in one or more NPNs, recording second MHI associated with the visited NPN cells; and After subsequently connecting to a first network, sending one or more MHI reports to the first network, the one or more MHI reports comprising one or more of: at least a portion of the first MHI; and at least a portion of the second MHI. A2.   The method of embodiment A1, wherein when the first network is a PN, the one or more MHI reports are configured according to one of the following: A single MHI report including at least part of the first MHI but not including the second MHI; A single MHI report including the first MHI and the second MHI; or A first MHI report including the first MHI and a second MHI report including the second MHI. A3.   The method of embodiment A2, wherein the at least part of the first MHI included in the single MHI report corresponds to one of the following: All first MHIs collected for all visited PN cells; or First MHIs collected only for visited PN cells associated with the first network. A4.   The method of any one of embodiments A1 to A3, when the first network is an NPN, the one or more MHI reports are configured according to one of the following: A single MHI report including at least part of the second MHI but not including the first MHI; A single MHI report including the first MHI and the second MHI; or A first MHI report including the first MHI and a second MHI report including at least part of the second MHI. A5.   The method of embodiment A4, wherein the at least part of the second MHI included in the single MHI report or the second MHI report corresponds to one of the following: All second MHIs collected for all visited NPN cells; or Second MHIs collected only for visited NPN cells associated with the first network. A6.   The method of any of embodiments A4 to A5, further comprising, after sending the single MHI report that includes at least a portion of the second MHI but does not include the first MHI, deleting the first MHI in response to the earlier of the following events: Connecting to a second network that is a PN and sending the first MHI to the second network; or Expiration of a time limit without sending the first MHI to a PN. A7.   The method of any one of embodiments A2 to A6, wherein for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, each MHI report entry corresponds to a visited cell and indicates one of the following for the visited cell: Whether the visited cell is associated with a PN or an NPN; or Whether information reported for the visited cell should be disclosed to other networks. A8.   The method of embodiment A7, wherein each MHI report entry corresponding to a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell. A9.   The method of any one of embodiments A2 to A8, wherein each MHI reporting entry corresponding to a visited NPN cell includes a first indication of a duration that the UE spent in the visited NPN cell and a second indication that the visited NPN cell is associated with one of: an NPN; or a network and/or a network type that cannot be disclosed. A10. The method of any one of embodiments A1 to A9, wherein one of the following applies: The first MHI and the second MHI are recorded in separate UE variables; or The first MHI and the second MHI are recorded in a single UE variable. A11. A method as in any one of embodiments A1 to A10, wherein: The method further includes receiving an information request for MHI for PN records and MHI for NPN records from the first network after subsequently connecting to the first network; and Sending the one or more MHI reports is in response to the information request. A12. A method as in embodiment A11, wherein the information request includes one of the following: A single indication of a request for MHI for PN records and MHI for NPN records; or A first indication of a request for MHI for PN records and a second indication of a request for MHI for NPN records. A13. The method of any one of embodiments A1 to A12 further comprises receiving a configuration for recording and reporting MHI from the first network or from a second network, wherein recording the first and second MHIs and sending the one or more MHI reports are based on the configuration. B1.   A method for a radio access network (RAN) node in a first network, the method comprising: receiving one or more mobility history information (MHI) reports from a user equipment (UE), the one or more MHI reports comprising one or more of the following: at least a portion of a first MHI recorded by the UE when visiting cells in one or more public networks (PNs), and at least a portion of a second MHI recorded by the UE when visiting cells in one or more non-public networks (NPNs); identifying a second RAN node based on the one or more received MHI reports; and sending at least a portion of the one or more received MHI reports to the second RAN node. B2.   The method of embodiment B1, wherein when the first network is a PN, the one or more MHI reports are configured according to one of the following: A single MHI report including at least part of the first MHI but not including the second MHI; A single MHI report including the first MHI and the second MHI; or A first MHI report including the first MHI and a second MHI report including the second MHI. B3.   The method of embodiment B2, wherein the at least part of the first MHI included in the single MHI report corresponds to one of the following: All first MHIs collected for all visited PN cells; or First MHIs collected only for visited PN cells associated with the first network. B4.   The method of any one of embodiments B1 to B3, when the first network is an NPN, the one or more MHI reports are configured according to one of the following: A single MHI report that includes at least part of the second MHI but does not include the first MHI; A single MHI report that includes the first MHI and the second MHI; or A first MHI report that includes the first MHI and a second MHI report that includes at least part of the second MHI. B5.   The method of embodiment B4, wherein the at least part of the second MHI included in the single MHI report or the second MHI report corresponds to one of the following: All second MHIs collected for all visited NPN cells; or Second MHIs collected only for visited NPN cells associated with the first network. B6.   The method of any one of embodiments B2 to B5, wherein for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, each MHI report entry corresponds to a visited cell and indicates one of the following for the visited cell: Whether the visited cell is associated with a PN or an NPN; or Whether information reported for the visited cell should be disclosed to other networks. B7.   The method of embodiment B6, wherein each MHI report entry corresponding to a visited NPN cell includes a cell global identifier (CGI) of the visited NPN cell. B8.   A method as in any one of embodiments B2 to B7, wherein each MHI report entry corresponding to a visited NPN cell comprises a first indication of a duration that the UE spent in the visited NPN cell and a second indication that the visited NPN cell is associated with one of: an NPN; or a network and/or a network type that cannot be disclosed. B9.   A method as in any one of embodiments B1 to B8, wherein: The method further comprises sending an information request for the MHI for the PN record and the MHI for the NPN record to the UE; and Receiving the one or more MHI reports is in response to the information request. B10.  A method as in Example B9, wherein the information request includes one of: A single indication of a request for MHI for PN recording and MHI for NPN recording; or A first indication of a request for MHI for PN recording and a second indication of a request for MHI for NPN recording. B11.  A method as in any one of Examples B1 to B11, further comprising sending a configuration for recording and reporting MHI to the UE, wherein the content of the one or more MHI reports is based on the configuration. B12.  A method as in any one of embodiments B1 to B11, wherein one of the following applies: The RAN node and the second RAN node are configured to be dually connected to the UE; or A cell served by the second RAN node is a target cell for a UE mobility program, and at least a portion of the received one or more MHI reports is sent to the second RAN node together with the mobility program. B13.  A method according to any one of embodiments B1 to B12, wherein: The one or more MHI reports include a first MHI report containing the at least a portion of the first MHI and a second MHI report containing the at least a portion of the second MHI; and The first and second MHI reports are sent to the second RAN node as one of the following: a single field of a single information element (IE) in a message; or a single IE in the message. B14. A method as in any one of embodiments B1 to B13, wherein the second RAN node serves one or more of the cells identified in the one or more MHI reports. C1. A user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN), the UE comprising: a communication interface circuit configured to communicate with RAN nodes in the PN and the NPN; and a processing circuit operably coupled to the communication interface circuit, whereby the processing circuit and the communication interface circuit are configured to perform operations corresponding to the method as in any one of embodiments A1 to A13. C2.   A user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN), the UE being further configured to perform operations corresponding to the method of any one of Examples A1 to A13. C3.   A non-transitory computer-readable medium storing computer-executable instructions, which when executed by a processing circuit of a user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN) configures the UE to perform operations corresponding to the method of any one of Examples A1 to A13. C4.   A computer program product comprising computer executable instructions that, when executed by a processing circuit of a user equipment (UE) configured to operate in a public network (PN) and a non-public network (NPN), configure the UE to perform operations corresponding to the method of any one of embodiments A1 to A13. D1.   A radio access network (RAN) node configured to operate in a first network, the RAN node comprising: a communication interface circuit configured to communicate with the UE; and a processing circuit operably coupled to the communication interface circuit, whereby the processing circuit and the communication interface circuit are configured to perform operations corresponding to the method of any one of embodiments B1 to B14. D2.   A radio access network (RAN) node configured to operate in a first network, the RAN node further configured to perform operations corresponding to the method of any one of embodiments B1 to B14. D3.   A non-transitory computer-readable medium storing computer-executable instructions, the computer-executable instructions, when executed by processing circuitry of a radio access network (RAN) node configured to operate in a first network, configure the RAN node to perform operations corresponding to the method of any one of embodiments B1 to B14. D4.   A computer program product comprising computer executable instructions which, when executed by processing circuitry of a radio access network (RAN) node configured to operate in a first network, configure the RAN node to perform operations corresponding to the method of any one of embodiments B1 to B14.

100:gNB 102:interface 110:central unit 120:distributed unit 122:F1 logic interface 130:distributed unit 132:F1 logic interface 140:Xn interface 150:gNB 152:interface 198:5th generation core (5GC) 199:Next generation radio access network (NG-RAN) 205:user equipment (UE) 210a:gNB 210b:gNB 211a:geographical coverage area 211b:geographical coverage area 220a:ng-eNB 220b:ng-eNB 221a:geographical coverage area 221b:geographical coverage area 230a: Access and Mobility Management Function (AMF) 230b: Access and Mobility Management Function (AMF) 240a: User Plane Function (UPF) 240b: User Plane Function (UPF) 250a: Policy Control Function (PCF) 250b: Policy Control Function (PCF) 260a: Network Exposure Function (NEF) 260b: Network Exposure Function (NEF) 298: Fifth Generation Core (5GC) 299: NG-Radio Access Network (RAN) 310: User Equipment (UE) 320: gNB 330: Access and Mobility Management Function (AMF) 1110: Block 1120: Block 1130: Block 1140: Block 1150: Block 1160: Block 1210: Block 1220: Block 1230: Block 1240: Block 1250: Block 1310: Block 1320: Block 1330: Block 1340: Block 1350: Block 1360: Block 1410: Block 1420: Block 1430: Block 1440: Block 1450: Block 1500: Communication system 1502: Telecommunication network 1504: Access network 1506: Core network 1508: Core network node 1510A: Network node 1510B: Network node 1512A to 1512D: User equipment (UE) 1514: Hub 1516: Host 1600: User equipment (UE) 1602: Processing circuit 1604: Bus 1606: Input/output interface 1608: Power supply 1610: Memory 1612: Communication interface 1614: Application program 1616: Data 1618: Transmitter 1620: Receiver 1622: Antenna 1700: Network node 1702: Processing circuit 1704: Memory 1704a: Computer program 1706: Communication interface 1708: Power supply 1710: Antenna 1712: RF transceiver circuit 1714: Baseband processing circuit 1716: Port/terminal 1718: Radio front-end circuit 1720: Filter 1722: Amplifier 1800: Host 1802: Processing circuit 1804: Bus 1806: Input/output interface 1808: Network interface 1810: Power supply 1812: Memory 1814: Host application 1816: Data 1900: Virtual environment 1902: Application/virtual device 1904: Hardware 1904a: Computer Program 1906: Virtualization Layer 1908A: Virtual Machine (VM) 1908B: Virtual Machine (VM) 1910: Management and Orchestration 1912: Control System 2002: Host 2004: Network Node 2006: User Equipment (UE) 2008: Steps 2010: Steps 2012: Steps 2014: Steps 2016: Steps 2018: Steps 2020: Steps 2022: Steps 2050: Over-the-Top (OTT) Connections 2060: Connections 2070: Wireless Connections

Figures 1-2 show two high-level views of an exemplary 5G/NR network architecture.

FIG3 shows an exemplary NR user plane (UP) and control plane (CP) protocol stack.

FIG. 4 shows an ASN.1 data structure of an exemplary VisitedCellInfoList information element (IE).

FIG. 5 shows an ASN.1 data structure of an exemplary UEInformationRequest message.

FIG. 6 shows an ASN.1 data structure of an exemplary UEInformationResponse message.

7 to 9 show the ASN.1 data structures of various exemplary VisitedCellInfoList IEs according to various embodiments of the present invention.

FIG. 10 shows an ASN.1 data structure of an exemplary UEInformationRequest message according to various embodiments of the present invention.

FIG. 11 shows a flow chart of an exemplary method for a UE (e.g., a wireless device) according to various embodiments of the present invention.

Figure 12 shows a flow chart of an exemplary method for a RAN node (e.g., base station, eNB, gNB, ng-eNB, etc.) according to various embodiments of the present invention.

FIG. 13 shows a flow chart of another exemplary method for a UE (e.g., a wireless device) according to various embodiments of the present invention.

Figure 14 shows a flow chart of another exemplary method for a RAN node (e.g., base station, eNB, gNB, ng-eNB, etc.) according to various embodiments of the present invention.

FIG15 shows a communication system according to various embodiments of the present invention.

FIG16 shows a UE according to various embodiments of the present invention.

Figure 17 shows a network node according to various embodiments of the present invention.

FIG. 18 shows a host computing system according to various embodiments of the present invention.

19 is a block diagram of a virtualization environment in which functions implemented by some embodiments of the present invention may be virtualized.

Figure 20 illustrates communication between a host computing system, a network node, and a UE via multiple connections, at least one of which is wireless, according to various embodiments of the present invention.

1310: Block

1320: Block

1330: Block

1340: Block

1350: Block

1360: Block

Claims (43)

A method for a user equipment (UE) configured to operate in a public network and a non-public network, the method comprising: recording (1320) first movement history information (MHI) associated with one or more public networks and/or visited cells in the one or more public networks; recording (1330) second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks; and after subsequently connecting to a first network, sending (1350) one or more MHI reports to the first network, the one or more MHI reports comprising one or more of: at least a portion of the recorded first MHI; and at least a portion of the recorded second MHI. The method of claim 1, wherein the recorded second MHI includes an indication of a duration that the UE spent outside a public network and one of: an indication of the duration spent in a non-public network, or an indication of the duration spent in a network whose type and/or identifier cannot be disclosed. The method of claim 2, wherein when the recorded second MHI for a non-public network includes the indication of the duration spent in a non-public network, the recorded second MHI also includes an identification code of the non-public network. A method as claimed in any one of claims 1 to 3, wherein the recorded first MHI comprises an indication of a duration that the UE spent outside a non-public network and one of: an indication of the duration spent in a public network, or an indication of the duration spent in a network whose type and/or identifier cannot be disclosed. A method as claimed in any one of claims 1 to 3, wherein for each visited cell in a non-public network, the recorded second MHI includes an indication of a duration of time that the UE spent in the visited cell and one of: an indication that the visited cell is part of a non-public network; or an indication that the visited cell is part of a network whose type and/or identifier cannot be disclosed. A method as in any of claims 1 to 3, wherein the one or more MHI reports are configured according to one of the following: A single MHI report that includes at least a portion of the first MHI but does not include the second MHI; A single MHI report that includes at least a portion of the second MHI but does not include the first MHI; A single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI; or A first MHI report that includes at least a portion of the first MHI and a second MHI report that includes at least a portion of the second MHI. The method of claim 6, wherein when the first network is a public network, the at least a portion of the first MHI included in the single MHI report corresponds to one of the following: All first MHIs recorded for all visited public networks and/or all visited cells in a public network; or Only the first MHI recorded for the first network and/or the visited cells in the first network. The method of claim 6, wherein when the first network is a non-public network, the at least a portion of the second MHI included in the single MHI report or the second MHI report corresponds to one of the following: All second MHIs recorded for all visited non-public networks and/or all visited cells in non-public networks; or Only the second MHI recorded for the first network and/or the visited cells in the first network. The method of claim 6, further comprising, after sending (1350) the single MHI report including at least a portion of the second MHI but not including the first MHI, discarding the first MHI in response to the earlier of the following events: connecting to a second network that is a public network and sending the first MHI to the second network; or a time limit expires without sending the first MHI to a public network. The method of claim 6, wherein for any single MHI report that includes at least a portion of the first MHI and at least a portion of the second MHI, at least one entry in the MHI report is associated with at least one respective visited cell, and each of the at least one entry indicates one of the following for the associated visited cell: Whether the visited cell is associated with a public network or a non-public network; or Whether information reported for the visited cell should be disclosed to other networks. A method as claimed in claim 10, wherein each entry associated with a visited NPN cell includes a cell global identification code (CGI) of the visited NPN cell. A method as claimed in any one of claims 1 to 3, wherein one of the following applies: The first MHI and the second MHI are recorded in separate UE variables; or The first MHI and the second MHI are recorded in a single UE variable. A method as in any of claims 1 to 3, wherein: the method further comprises, after subsequently connecting to the first network, receiving (1340) an information request for MHIs recorded for public networks and MHIs recorded for non-public networks from the first network; and sending (1350) the one or more MHI reports in response to the information request. The method of claim 13, wherein the information request includes one of the following: a single indication of a request for an MHI for public network records and an MHI for non-public network records; or a first indication of a request for an MHI for public network records and a second indication of a request for an MHI for non-public network records. The method of any of claims 1 to 3, further comprising receiving (1310) a configuration for recording and reporting MHI from the first network or from a second network, wherein recording (1320, 1330) the first and second MHIs and sending (1350) the one or more MHI reports are based on the configuration. A method for a radio access network (RAN) node configured to operate in a first network, the method comprising: receiving (1430) one or more mobility history information (MHI) reports from a user equipment (UE), the one or more MHI reports comprising one or more of the following recorded by the UE: a first MHI associated with one or more visited public networks and/or visited cells in the one or more public networks, and a second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks; identifying (1440) a second RAN node based on the received one or more MHI reports; and sending (1450) at least a portion of the received one or more MHI reports to the second RAN node. The method of claim 16, wherein the second MHI includes an indication of a duration that the UE spent outside a public network and one of: an indication of the duration spent in a non-public network, or an indication of the duration spent in a network whose type and/or identifier cannot be disclosed. The method of claim 17, wherein when the second MHI includes the indication of the duration spent in a non-public network, the second MHI also includes an identification code of the non-public network. A method as claimed in any of claims 16 to 18, wherein the first MHI comprises an indication of a duration that the UE spent outside a non-public network and one of: an indication of the duration spent in a public network, or an indication of the duration spent in a network whose type and/or identifier cannot be disclosed. A method as claimed in any of claims 16 to 18, wherein for each visited cell in a non-public network, the second MHI comprises an indication of a duration that the UE spent in the visited cell and one of: an indication that the visited cell is part of a non-public network; or an indication that the visited cell is part of a network whose type and/or identification code cannot be disclosed. A method as in any of claims 16 to 18, wherein the one or more MHI reports are configured according to one of the following: A single MHI report that includes the first MHI but does not include the second MHI; A single MHI report that includes the second MHI but does not include the first MHI; A single MHI report that includes the first MHI and the second MHI; or A first MHI report that includes the first MHI and a second MHI report that includes the second MHI. The method of claim 21, wherein when the first network is a public network, the first MHI included in the single MHI report corresponds to one of the following: All first MHIs recorded for all visited public networks and/or all visited cells in a public network; or Only the first MHI recorded for the first network and/or the visited cells in the first network. The method of claim 21, wherein when the first network is a non-public network, the second MHI included in the single MHI report or the second MHI report corresponds to one of the following: All second MHIs recorded for all visited non-public networks and/or all visited cells in non-public networks; or Only the second MHI recorded for the first network and/or the visited cells in the first network. The method of claim 21, wherein for any single MHI report including the first MHI and the second MHI, at least one entry in the MHI report is associated with at least one respective visited cell, and each of the at least one entry indicates one of the following for the associated visited cell: Whether the visited cell is associated with a public network or a non-public network; or Whether information reported for the visited cell should be disclosed to other networks. A method as claimed in claim 24, wherein each entry associated with a visited NPN cell includes a cell global identification code (CGI) of the visited NPN cell. The method of claim 21, wherein the first MHI report and the second MHI report are sent to the second RAN node as one of: separate fields of a single information element (IE) in a message; or separate IEs in the message. A method as in any one of claim items 16 to 18, wherein: the method further comprises sending (1420) to the UE an information request for MHI recorded for public networks and MHI recorded for non-public networks; and receiving (1430) the one or more MHI reports in response to the information request. The method of claim 27, wherein the information request includes one of the following: a single indication of a request for an MHI for public network records and an MHI for non-public network records; or a first indication of a request for an MHI for public network records and a second indication of a request for an MHI for non-public network records. The method of any of claims 16 to 18, further comprising sending (1410) a configuration for recording and reporting MHI to the UE, wherein the content of the one or more MHI reports is based on the configuration. A method as claimed in any one of claims 16 to 18, wherein one of the following applies: the RAN node and the second RAN node are configured to be dually connected to the UE; or a cell served by the second RAN node is a target cell for a UE mobility procedure, and at least a portion of the received one or more MHI reports is sent to the second RAN node together with the mobility procedure. A method as in any of claims 16 to 18, wherein the second RAN node serves one or more of the cells identified in the one or more MHI reports. A user equipment UE (205, 310, 1512, 1600, 2006) configured to operate in a public network (1502) and a non-public network (1502), the UE comprising: A communication interface circuit (1610) configured to communicate with radio access network RAN nodes (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) in the public network and the non-public network; and A processing circuit (1602) operably coupled to the communication interface circuit, whereby the processing circuit and the communication interface circuit are configured to: Record first mobile history information MHI associated with one or more public networks and/or with visited cells in the one or more public networks; Recording a second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks; and After subsequently connecting to a first network, sending one or more MHI reports to the first network, the one or more MHI reports including one or more of: at least a portion of the recorded first MHI; and at least a portion of the recorded second MHI. The UE of claim 32, wherein the processing circuit and the communication interface circuit are further configured to perform operations corresponding to the method of any one of claims 2 to 15. A user equipment UE (205, 310, 1512, 1600, 2006) configured to operate in a public network (1502) and a non-public network (1502), the UE being further configured to: record first movement history information MHI associated with one or more public networks and/or with visited cells in the one or more public networks; record second MHI associated with one or more non-public networks and/or with visited cells in the one or more non-public networks; and after subsequently connecting to a first network, send one or more MHI reports to the first network, the one or more MHI reports comprising one or more of: at least a portion of the recorded first MHI; and at least a portion of the recorded second MHI. The UE of claim 34 is further configured to perform operations corresponding to the method of any one of claims 2 to 15. A non-transitory computer-readable medium (1610) storing computer-executable instructions, which, when executed by a processing circuit (1602) of a user equipment UE (205, 310, 1512, 1600, 2006) configured to operate in a public network (1502) and a non-public network (1502), configure the UE to perform operations corresponding to the method of any one of claims 1 to 15. A computer program product (1614) comprising computer executable instructions which, when executed by a processing circuit (1602) of a user equipment UE (205, 310, 1512, 1600, 2006) configured to operate in a public network (1502) and a non-public network (1502), configure the UE to perform operations corresponding to a method as described in any one of claims 1 to 15. A radio access network RAN node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) configured to operate in a first network (1502), the RAN node comprising: Communication interface circuit (1706, 1904) configured to communicate with user equipment UE (205, 310, 1512, 1600, 2006) and a second RAN node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004); and Processing circuit (1702, 1904) operably coupled to the communication interface circuit, whereby the processing circuit and the communication interface circuit are configured to: Receiving one or more mobility history information (MHI) reports from a UE, the one or more MHI reports comprising one or more of the following recorded by the UE: A first MHI associated with one or more visited public networks and/or visited cells in the one or more public networks, and A second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks; Identifying the second RAN node based on the one or more received MHI reports; and Sending at least a portion of the one or more received MHI reports to the second RAN node. A RAN node as claimed in claim 38, wherein the processing circuit and the communication interface circuit are further configured to perform operations corresponding to the method of any one of claims 17 to 31. A radio access network RAN node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) configured to operate in a first network (1502), the RAN node being further configured to: receive one or more mobility history information MHI reports from a user equipment UE (205, 310, 1512, 1600, 2006), the one or more MHI reports comprising one or more of the following recorded by the UE: a first MHI associated with one or more visited public networks and/or visited cells in the one or more public networks, and a second MHI associated with one or more non-public networks and/or visited cells in the one or more non-public networks; Identifying a second RAN node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) based on the received one or more MHI reports; and Sending at least a portion of the received one or more MHI reports to the second RAN node. The RAN node of claim 40 is further configured to perform operations corresponding to the method of any one of claims 17 to 31. A non-transitory computer-readable medium (1704, 1904) storing computer-executable instructions which, when executed by processing circuitry (1702, 1904) of a radio access network (RAN) node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) configured to operate in a first network (1502), configure the RAN node to perform operations corresponding to the method of any one of claims 16 to 31. A computer program product (1704a, 1904a) comprising computer executable instructions which, when executed by processing circuitry (1702, 1904) of a radio access network (RAN) node (100, 150, 210, 220, 320, 1510, 1700, 1902, 2004) configured to operate in a first network (1502), configure the RAN node to perform operations corresponding to the method of any one of claims 16 to 31.