Collaborative detection of MITM attacks

Abstract

Systems and methods for generating and verifying probing messages are provided. A network node generates a probing message for a test case, wherein the probing message is indistinguishable from normal network signaling messages. Identical probing messages are generated at both the probing node and the verification node. Responsive to determining that the network node is the probing node, it triggers transmission of the probing request message through a radio access network. Responsive to determining that the network node is the verification node, it receives a message and verifies it as compared to the generated probing request message.

Description

P111304W001COI J ABORATIVE DETECTION OF MITM ATTACKSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 690,657 filed on September 4, 2024, the entire contents of which are hereby incorporated by reference.TECHNICAL FIELD

[0002] The present disclosure generally relates to wireless communications and wireless communication networks.INTRODUCTION

[0003] Radio access networks (RAN) are moving to software-ization and virtualization. Namely, CloudRAN, virtual RAN (vRAN) and Open RAN (O-RAN) rely on using virtualization and containerization technologies for even faster and more agile development and deployment of RAN. In the following, for simplification, vRAN will be used to denote CloudRAN and O-RAN. This allows them to deploy mobile networks over general-purpose computing platforms in a cloudbased environment. This will lead to the expansion of the attack surface and may lead to new attacks that have not been seen before.

[0004] A threat inventory for the O-RAN system can be developed to provide a mapping between threats, vulnerabilities, and assets. Threats have been grouped into two categories: (1) “O- RAN specific” comprises threats directly relating to O-RAN components and interfaces; (2) “General” covers threats relating to physical, open source, virtualization, loT, and radio aspects. The threat inventory provides all details of each individual threat: Threat agents, vulnerabilities, threatened assets, and affected components. Several described threats can lead to higher risk to security including unauthorized access to O-RAN components and compromise of the O-RAN system. It is plausible that, for instance, a total compromise of the RAN by a malicious attacker that circumvents the security controls, turns them off, and abuses of the functionality of the RAN to perform man-in-the-middle (MiTM) attacks such that modifying, injecting, deleting messages at the application level leading to results similar to existing attacks such as bidding down attack,P111304W001GUTI replay, battery drain attacks, identification attacks etc. These attacks are possible as device capabilities are sent in clear.

[0005] These attacks in previous telecom generations were mainly allowed by an attacker introducing a fake base station with / without a malicious UE between the legitimate UE and the legitimate gNB. However, with virtualization, the expansion of the attack surface due to multivendor, multi-tenant cloud-based environment, new and stealthier attacks can occur where the attacker takes control of the legitimate RAN to enable those attacks. The threat model related to fake base station attacks in previous generations assumes that the RAN is trusted but the base stations are not. The current threat model assumes that the vRAN and the base station are both untrusted (zero-trust should be applied). The 0-RAN architecture is being developed using zero trust (ZT) and zero trust architecture (ZTA) principles. Zero trust is an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Zero trust also assumes that an adversary can always be in the network.

[0006] Drive testing is a method of measuring and assessing the coverage, capacity, and quality of service of a mobile radio network. It is principally applied in both the planning and optimization stages of network development. Drive tests are the most common measurement tool used by operators, to probe the quality status and solve network problems. Drive testing can be done to:

[0007] - Check deployment of new network sites to meet coverage, capacity, and quality requirements.

[0008] - Optimize the network

[0009] - Benchmark performance

[0010] - Troubleshoot

[0011] - Verify the performance after an upgrade or reconfiguration of the network

[0012] The dataset collected during drive testing field measurements can include Signal intensity, Signal quality, interference, Dropped calls, Blocked calls, Call statistics, Service level statistics, Handover information, Neighboring cell information, and GPS location coordinates. Optimization and troubleshooting information are more typically used to aid in finding specificP111304W001 problems during the rollout phases of new networks or observe specific problems reported by consumers during the operational phase of the network lifecycle.

[0013] Equipment used in drive testing can include:

[0014] - Laptop computer (or another similar device)

[0015] - Data collecting software installed on the laptop

[0016] - A security Key - dongle- common to these types of software

[0017] - One mobile phone for each mobile network that is being tested

[0018] - One GPS antenna

[0019] Test methods can include:

[0020] - Idle: used to record the network condition at idle state and the level of C / I on BCCH

[0021] - Dedicated shortCall (120sec): mainly used for testing the accessibility and mobility of the network. Also used for checking successful completion of call

[0022] - Dedicated l ongCall (entire duration of drive test): mainly used to test the retainability and sustainability e.g., call drop rate, Handover success rate, etc.

[0023] Data collected using software TEMS (test mobile system), technology used by telecom operators to measure analyze, and optimize their mobile networks. It is considered a basic tool to perform wireless network drive testing, benchmarking, and analysis. Key performance indicators: accessibility (% call setup success rate, retainability % dropped calls, mobility- %handover success rate, % RF coverage, % Rx Quality, % carrier over Interference.

[0024] Bidding down attack and UE Capability Lists: Bidding down attacks aims at downgrading the service for the UE from 5G to previous mobile network generations. This is a typical MITM attacker where the attacker modifies the message the UE capabilities sent in clear by the UE to the core. During the registration, the UE requests for two types of capabilities to the core via vRAN: radio (consisting of parameters for both, the RAN and the core) and security. Examples of radio capabilities include the data rate of the UE and supported bands. The request for those capabilities is sent in plaintext before a secure channel is established between the UE and core using security capabilities. As per the latest 3GPP specification, there are about 950 capabilities that a UE can support. It consists of multiple categories of parameters of which some are common to all UEs whereas the rest are unique to only a few. With the increasing number of parameters, the attack surface also proportionally increases. The modification of each parameterP111304W001 could lead to a unique attack. Other capabilities such as inactiveState and MaxDLDataRate could be attacked and could lead to increased power consumption and decreased data rate respectively.

[0025] State Management in 5G: Each of the three components of a 5G system (means UE, RAN and Core) periodically transitions through a predefined set of states. The UE switches back and forth between two states: RM-REGISTERED and RM-DEREGISTERED (where RM indicates Registration Management). The core switches between CM-CONNECTED and CM- IDLE (where CM stands for Connection Management). The states of UE and core coincide, i.e., whenever the UE transitions from RM-REGISTERED to RM-DEREGISTERED, the core transitions from CM-CONNECTED to CM-IDLE and vice-versa. From the perspective of the vRAN, there are three states a UE can be in: RRC ACTIVE, RRC INACTIVE and RRC IDLE. RM-REGISTERED / CM-CONNECTED correspond to RRC ACTIVE and RRC INACTIVE, respectively. RM-DEREGISTERED / CM-IDLE corresponds to RRC IDLE, where RRC stands for the Radio Resource Control.

[0026] There exists a need for enhanced security detection mechanisms that can effectively operate in virtualized radio access network environments and provide comprehensive monitoring capabilities across multiple network components and interfaces.SUMMARY

[0027] It is an object of the present disclosure to obviate or mitigate at least one disadvantage of the prior art.

[0028] There are provided systems and methods for generating and verifying probing request messages.

[0029] In a first aspect there is provided a method performed by a network node configured to perform a probing function. The network node can comprise a radio interface and processing circuitry and be configured to generate at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages. The network node determines whether it is a probing node for the test case. Responsive to determining that the network node is the probing node, the network node triggers transmission of the generated at least one probing request message through a radio access network.P111304W001

[0030] In some embodiments, the network node is a wireless device. In other embodiments, the network node is a core network node.

[0031] In some embodiments, generating the at least one probing request message can comprise using historical data including behavior aspects of user equipment based on at least one of user equipment communication parameters and radio resource control state transitions. The user equipment communication parameters can include at least one of: a radio capability, a data rate capability, a supported frequency band, an inactive state parameter, and / or a maximum downlink data rate parameter. The radio resource control (RRC) state transitions can include transitions between RRC ACTIVE, RRC INACTIVE, and / or RRC IDLE states corresponding to user equipment registration and connection management states.

[0032] In some embodiments, the generative machine learning model is a deterministic generative adversarial network that generates identical probing request messages at both the probing node and a verification node using a same seed value and same historical data. The deterministic generative adversarial network can take as input the seed value and historical data consisting of the user equipment communication parameters. The historical data can include at least one of: a device identifier, a timestamps, and / or a location from which probing requests should be sent.

[0033] In some embodiments, the generative machine learning model further comprises using a linear assignment problem algorithm to replace generated timestamps and locations with timestamps and locations for testing probes that represent a closest match. The linear assignment problem algorithm can be a Jonker- Volgenant algorithm that forms a bipartite graph between generated values and values to be tested to minimize distinguishability of resulting probes.

[0034] In some embodiments, the at least one probing request message is generated to test for at least one of message modification attacks, message injection attacks, and message deletion attacks.

[0035] In some embodiments, triggering transmission can include determining devices by their international mobile subscriber identity to which the at least one probing request message should be sent.

[0036] In some embodiments, the network node can store the generated at least one probing request message for later verification.P111304W001

[0037] In another aspect there is provided a method performed by a network node configured to perform a verification function. The network node can comprise a radio interface and processing circuitry and be configured to generate at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages. The network node determine that it is a verification node for the test case. The network node receives a first message from a radio access network and identifies whether the received first message corresponds to a probing request message by matching a subscriber identity associated with the first message with probing node identities. Responsive to identifying that the received first message corresponds to a probing request message, the network node verifies the first message by comparing the received first message with the generated at least one probing request message.

[0038] In some embodiments, the network node is a wireless device. In other embodiments, the network node is a core network node.

[0039] In some embodiments, responsive to determining that the network node is the verification node, the network node stores the generated at least one probing request message for later verification.

[0040] In some embodiments, the subscriber identity is an international mobile subscriber identity.

[0041] In some embodiments, verifying the first message further comprises extracting attributes to be tested from the received first message and comparing the extracted attributes with corresponding expected attributes from the generated at least one probing request message. The expected attributes of the received first message can be generated using a generative machine learning model with the same seed value and historical data used to generate the at least one probing request message. The generative machine learning model can be a deterministic generative adversarial network. The deterministic generative adversarial network can generate identical expected attributes at both a probing node and the verification node using a same seed value and historical data. In some embodiments, the attributes can include user equipment communciation parameters.

[0042] In some embodiments, the network node can generate an alert in response to a verification result. The alert can identify a type of man-in-the-middle attack selected from messageP111304W001 modification attack, message injection attack, and message deletion attack. In some embodiments, the network node can generate an alert for message injection attack when the received first message does not correspond to any expected probing request message. In some embodiments, the network node can generate an alert for message deletion attack when an expected probing request message is not received within a predetermined time threshold.

[0043] The various aspects and embodiments described herein can be combined alternatively, optionally and / or in addition to one another.

[0044] Other aspects and features of the present disclosure will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Embodiments of the present disclosure will now be described, by way of example only, with reference to the attached Figures, wherein:

[0046] Figure 1 is an example communication system;

[0047] Figure 2 illustrates an overview of the RANWatson system;

[0048] Figure 3 illustrates an example overview of the RANWatson workflow;

[0049] Figure 4 illustrates an example workflow of the RANWatson manager function;

[0050] Figure 5 illustrates an example workflow of the RANWatson Agent probing function;

[0051] Figure 6 illustrates an example of probing UE generation using GAN;

[0052] Figure 7 illustrates an example workflow of the verification function;

[0053] Figure 8 is a flow chart illustrating a method performed by a network node;

[0054] Figure 9 is a block diagram of an example wireless device;

[0055] Figure 10 is a block diagram of an example network node;

[0056] Figure 11 is a block diagram illustrating an example virtualization environment.DETAILED DESCRIPTION

[0057] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the description and willP111304W001 recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

[0058] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0059] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0060] Figure 1 illustrates an example of a communication system 100 in accordance with some embodiments.

[0061] In the example, the communication system 100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 102 includes one or more Open- RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes toP111304W001 implement one or more functionalities of any node in the telecommunication network 102, including one or more network nodes 110 and / or core network nodes 108.

[0062] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112A, 112B, 112C, and 112D (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections.

[0063] Example wireless communications over 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. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0064] The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with theP111304W001 network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102.

[0065] In the depicted example, the core network 106 connects the network nodes 110 to one or more host computing systems, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g., core network node 108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0066] The host 116 may be under the ownership or control of a service provider other than an operator or provider of the access network 104 and / or the telecommunication network 102. The host 116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0067] As a whole, the communication system 100 of Figure 1 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal MobileP111304W001Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the 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.

[0068] In some examples, the telecommunication network 102 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0069] In some examples, the UEs 112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi -RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0070] In the example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112C and / or 112D) and network nodes (e.g., network node HOB). In some examples, the hub 114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 114 may be a broadband router enabling access to the core network 106 for the UEs. As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 114. AsP111304W001 another example, the hub 114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 114 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0071] The hub 114 may have a constant / persistent or intermittent connection to the network node HOB. The hub 114 may also allow for a different communication scheme and / or schedule between the hub 114 and UEs (e.g., UE 112C and / or 112D), and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Moreover, the hub 114 may be configured to connect to an M2M service provider over the access network 104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node HOB. In other embodiments, the hub 114 may be a nondedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 110B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0072] Note that some embodiments given herein refer to a 3 GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0073] Note that, in the description herein, reference may be made to the term “cell”. However, particularly with respect to 5G / NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0074] Returning to the discussion of MiTM detection, existing solutions consider conventional RAN where MiTM attacks are generally driven by either Fake Base Stations or FBS (a.k.a. false base station, rogue base station, IMSI catcher or stingray), a radio network sniffer tools, or signalP111304W001 injectors. With the advent of vRAN and Open RAN, MiTM attackers are no longer limited to these means. Those works can be categorized into two categories: FBS detection (or localization) and Protocol analysis-based approaches. The FBS detection works can be classified as either UE- centric, crowd-sourced-based, network-centric, protocol-based, or based on a combination of those. None of the existing works have considered compromised vRAN and none of them have proposed the generation of indistinguishable probing requests at both the UE and the core. Embodiments described herein differ with these solutions by using both the set of virtual UE (probing UEs) and the core views to enable the detection of MiTM attacks. Existing work generally assumes the network core and the RAN is to be trusted, as opposed to the assumption that the RAN can be compromised. While they either rely on the RAN or the UE to detect FB-based attacks, embodiments described herein rely on a set of UEs and the core. Existing solutions do not take into account a strong malicious attacker at the vRAN that tries to evade the detection mechanisms.

[0075] Recent works propose to detect FBS using new capabilities in vRAN (e.g., xAPP, rAPP). Security solutions deployed in the RAN can be compromised by an attacker (circumventing the security tools, disabling them, poison their data) and thus cannot be relied on completely to detect a malicious actor gaining control of the RAN.

[0076] Existing solutions either need to modify the UE, the RAN, or communication protocols to detect attacks. The approach described herein does not modify either the UE, RAN, Core, or the communication protocol. It only requires monitor the traffic at UE and the Core to verify the sent probes.

[0077] Drive test: Existing solutions perform only testing of performance of the network and QoE was proposed for Mobile / cellular networks. Drive tests suffer from the same problem when it relies on only the UE to detect MiTM attack, which is mainly high number of false positives / negatives since they lack network state view. For example, they cannot distinguish genuine from fabricated network-initiated messages (e.g., attachReject messages). In contrast, embodiments described herein combine both UEs and core views, and thus can handle MiTM attacks in both directions.

[0078] Embodiments described herein provide a solution for detecting the presence of a MiTM attacker located in the vRAN (controlling it partly or completely) based on: (1) generating indistinguishable requests using generative ML approach (e.g., GAN) and shared data between aP111304W001 set of virtual (or regular) UEs and the core network side; (2) sending the generated requests from one end to the other end (through the untrusted vRAN); and (3) verifying at the receiving side (either the UE or the core) that the sent requests were not tampered with by a malicious adversary while being processed by the vRAN.

[0079] The whole system is presented to automatically detect the presence of MiTM attacker and identify its attack that might occur between UE mobile devices from one side (UE-side) and the mobile core network side (Core-side) based on probing and verification process occurring between a set of designated UE mobile devices and the Core network using indistinguishable probing request messages exchanged in both directions, without modification to the protocol.

[0080] The process includes generating a set of indistinguishable probing requests messages (using historical data including the behavior aspects of the UEs based on the UE capabilities and / or the RRC state transition) in collaborative way between the UE-side and the Core-side to obtain the same probing requests at both sides.

[0081] Some embodiments include detection of any type of MiTM attack (injection, modification, deletion) that can occur between the UEs and the core network, without being limited to FBS. Effective detection of MITM attacks that might occur from any malicious source between the UE and the core network including FBS, compromised RAN components (e.g., RU, CU) which can modify, inject, and delete, requests between UE and Core and the detection can be done for both attack directions (against the UE and against the core) at the same time.

[0082] Some embodiments leverage Generative ML to generate indistinguishable probing requests in the purpose of tempting the attacker to perform the attack on those probes so to be revealed. The proposed solution does not require modification of the protocol specification and can be applied independently of the protocol.

[0083] In the embodiments that follow, a solution referred to as “RANWatson” will be described that monitors the virtual RAN to detect the presence of smart and stealthy MitM attackers that try to intercept and modify, drop, or inject new 3 GPP signaling request messages between the UEs (mobile devices) and the core network (in both directions) either to perform DoS or to modify the service for his own benefits. RANWatson offers a higher detection rate, catching attackers with acceptable delay (minimizing the damage) while adding acceptable minimal overhead to the service.P111304W001

[0084] Figure 2 illustrates an overview of the RANWatson system. The primary idea behind RANWatson is leveraging two sides: The UE side with a set of UEs mobile devices and the core network side to detect the presence of a potential MiTM attacker located between them and eventually in the virtual RAN.

[0085] RANWatson generates a set of indistinguishable probing requests (that cannot be distinguished from normal UE requests) at both sides and then usies them in a probe-and-verify approach where one side plays the role of the prober and the other side the role of the verifier (and vice-versa) depending on the test case.

[0086] A test case is defined as what to verify, which could be an attribute of a message request (example radio capabilities in registration request message), or a message request injection (example Registration Reject message), or deletion.

[0087] This makes RANWatson different in that it employs a deceiving mechanism against a strong attacker that is stealth and smart by attacking the subset of the requests that he does not suspect to be probing requests so that he evades detection.

[0088] To achieve the probe-and-verify approach successfully, both sides need to be able to obtain / generate the same information. This information is used by both sides depending on the role for two different reasons: To build the probing requests by the prober (either in the UE-side or the core side) or to verify the probe after receiving the related messages by the verifier (either in the UE-side or the core side), which should eventually come from the virtual RAN (where the malicious attacker can act on them). The verification aims at ensuring that the received messages are the actual expected ones based on the sent probing messages. The presence of the attacker can be detected when the data received at the verifier side differs from the data expected to be received based on the request sent by the prober.

[0089] Thus, both sides need to share common data including (1) historical data related to the users of the existing UE’s, (2) the list of capabilities of all UE devices, (3) the list of attributes to be tested, and their valid values (domain ranges), (4) the pairs of attributes-value to be used for testing and (5) the time and location (e.g., the cell from which the UE should connect to send the probe) of the tests in addition to (6) same seed value and (7) Role-tag to identify the prober side and the verifier side.P111304W001

[0090] Furthermore, both UE and core side can use a generative ML model to generate probing requests. Example of these models is deterministic GAN (D-GAN), with the same input seed value, and the same historical data, etc., can generate the same set of indistinguishable probing requests at UE-side and at Core-side.

[0091] The system in Figure 2 is composed of a central manager and a number of agents distributed in a set of virtual UEs and the core network. Each agent is composed of a probing module and a verification module. The integrity of the exchanged data between the manager and the agent is important for the correct functioning of the approach. Therefore, it is important that a secure channel is maintained to ensure that all data shared is not being tampered. The working principle and workflow of each component are explained in the next section.

[0092] Figure 3 illustrates an example overview of the RANWatson workflow.

[0093] Both UE and core side agents perform the steps 1-2 for each test:

[0094] Step 1 : Agents generate indistinguishable probing request messages (independently being prober or verifier), taking into account who is the probing side, who is the verifier side, and the test case.

[0095] Step 2: Agents store the probing request messages to be used for later verification.

[0096] At the UE side, if identified to be the prober, the agent performs the following:

[0097] Step 3a: Agent determines the probing UEs (their IMSI).

[0098] Step 4a: Agent triggers sending the generated probing messages in Step 1 from the identified UEs is Step 3a.

[0099] At the UE side, if identified to be the verifier, the agent performs the following:

[0100] Step 5a: the agent receives request messages from the core by each probing UE.

[0101] Step 6a: the agent verifies each received request message (in Step 5a) with the stored indistinguishable probing request messages generated at step (Step 1).

[0102] Step 7: Generate and send alert messages based one the verification outcome.

[0103] At the Core side, if identified to be the prober, the agent performs the following:

[0104] Step 3b: Agent determines the probing UEs (their IMSI) to which the probes will be sent.

[0105] Step 4b: Agent triggers sending the generated probing messages in Step 1 from the core to the identified UEs is Step 3b.P111304W001

[0106] At the Core side, if identified to be the verifier, the agent performs the following:

[0107] Step 5b: the agent intercepts the received request messages from each probing UEs (identified by their IMSI).

[0108] Step 6b: the agent verifies each received request message (in Step5b) with the stored indistinguishable probing request messages generated at step (Step 1).

[0109] Step 7: Generate and send alert messages based one the verification outcome.

[0110] In one alternative for building probing traffic for each test case, all test cases can be probed together by just taking all historical traffic data from multiple users and use d-GAN to generate traffic that will be used to probe for testing everything.[oni] In another alternative, instead of using only time and location to build the indistinguishable behavior of probes, other behavioral characteristics can be taken into account, such as dataplane protocol, destination IP, etc.

[0112] In a non-limiting example, the overall approach can be explained based on the bidding down attack testing (e.g., UE capabilities instead of attributes). To detect such a potential MiTM attack, an example methodology follows:

[0113] A, Initialization and probes generation (at UE-side and core-side)

[0114] - First, the seed value and other data need to be shared between the agents deployed in the UEs and in the core network. The input data are the RRC state transition data obtained from historical traffic data, the capability list of all UEs devices with the range of their valid values, and the list of capability-value pairs to be tested. This seed and this input data are used to be able to generate the same set of attributes of the probing requests at both the UE and the core.

[0115] - Additionally, the time during which and the locations from where the probing request must occur might also be provided by the admin user as inputs.

[0116] - All agents (at both sides UE or core) generate a list of UEs that can cover all the capabilities to be tested and when / from which location they can be used for sending the probe request. This can be achieved by using the seed value, training data (e.g., RRC UE state transition data consisting of timestamps and locations - or cells - of when UE states change from activity to inactivity and vice versa), the capability lists of all the available devices, and the capability-value pair to be tested. More specifically, a D-GAN is used to produce identical output on both sides.P111304W001Each row of the D-GAN’s output contains the list of UE devices, the timestamp at which, and the location from where a given UE needs to send the probe.

[0117] - Capabilities of all available UEs are used to augment this output with the capabilities of the devices selected. This augmented output is checked against a list of all the capability-value pairs to be tested.

[0118] - If it covers all capability -values pairs, we proceed to reduce the number of UEs selected to a minimum by using the set cover algorithm. If it fails to cover all the capability -value pairs, we keep generating more data using D-GAN until all the pairs are covered. The reduction using a set cover algorithm makes RANWatson resource efficient. Only the minimum number of UEs needed to cover all the capabilities value pairs to be tested are used. This reduces the overhead experienced by the RAN and the core as fewer devices (and by extension probes) will be needed.

[0119] - The agent then replaces the generated timestamps and locations with the value to be tested. After receiving the minimum number of UEs from which to send the probes, we take the timestamp and location that the admin wants to test. Without this step, the generated probes could be sufficiently distinguishable as the user-defined timestamp and location would override the GAN-generated indistinguishable ones. To make the resultant timestamps and locations as indistinguishable as possible, we form a bipartite graph between the set of timestamps generated by D-GAN and the timestamps the admin wants to test. We use the LAPJV algorithm to find a one-to-one mapping between the two sets such that the sum of its edges is minimal. After obtaining the new bipartite graph, the values generated by D-GAN are replaced with the values to be tested. The same is done for the location values to be tested. Post this step, the set of indistinguishable probes is ready to be sent.

[0120] B, Probing (From UE-side)

[0121] Once the indistinguishable probes are ready, they are sent by the probing UE via the RAN to the Core so that they are used to lure the attacker to perform his MiTM attack on those probes.

[0122] C. Verification (from Core-side)

[0123] As soon as a request arrives at the core from vRAN, the agent at the core matches its subscriber identity (IMSI) with that of all the probing UEs. If there is a match, the agent processes it further, otherwise discards it. If the request is from a probing UE, it compares all capability -P111304W001 value pairs of the received request with the corresponding capability -value pairs of the expected request that was also generated at the core (see first point). For instance, for the capabilities testing the AMF function receives and stores the capabilities relayed by the vRAN. Thus, the corresponding message (UERadioCapabilitylnfoIndication) is checked and compared the capabilities in this message versus the capabilities generated initially synchronously by UE-side and Core-side agents. If any of the capability-value does not match, the agent identifies it as an indication of an attack by a malicious vRAN and raises an alarm.

[0124] Figure 4 illustrates an example workflow of the RANWatson manager function.

[0125] Step 1 : the Manager reads input consisting of data identified from (1) to (4) in Figure 2 and stores it in the local database.

[0126] Step 2: The Manager determines the role of the UE-side and the core-side agents (roletag prober / verifier) to test the read list of attributes to be tested.

[0127] Step 3 : Depending on the test and the role prober / verifier, the manager collects historical data and stores it in the local database. For example, if the prober is UE, collect behavior of different UEs’ users e.g., devices, timestamp, and location of the UE’s RRC-specific state transitions. This step can be triggered at a certain frequency to obtain new historical data (e.g., on daily basis)

[0128] Step 4a / 4b: Either step 4b is execute (if the process has been triggered to collect new historical data on daily basis) or step 4a is executed (if this is the initially collected historical data). The latter (Step 4b) lead to only sending the newly collected historical data to all agents through secure while the former leads to the Manager generating a seed value.

[0129] Step 5: The manager sends the respective role-tag for the UE and core, the seed, the historical data (5), and all data received as input in Step 1 to all agents through a secure channel.

[0130] Step 6: The Manager reads input consisting of testing data (the list of pairs of attributevalue - e.g., Capability-value pairs) and the testing parameters (timestamps when and location from where to send test probes).

[0131] Step 7: The manager sends testing data and testing parameters to all agents through a secure channel.

[0132] Figure 5 illustrates an example workflow of the RANWatson Agent probing function.P111304W001

[0133] Step 1 : The probing module receives and stores data from the Manager about a its roletag, the seed, the historical data (5), and all data (1) to (4) through a secure channel. If new Historical is available, the module receives it ins Step 1 (bis).

[0134] After this step, the module generates probing request messages following steps 2 to step 5 as follows:

[0135] Step 2: The module generates indistinguishable behavior (e.g., RRC transitions with timestamps and locations) from users’ historical data (5) using Generative ML (e.g., D-GAN).

[0136] Step 3: Check the coverage of to-be-tested attributes in the generated indistinguishable behavior and minimize the number of UEs devices covering these attributes. The cover set algorithm can be used for this task. To do so, this module takes as input the generated indistinguishable behavior of users as well as the (1) List of Capabilities of all UE devices, (2) List of attributes to be tested and their valid values related to UEs (e.g., Capability lists and their valid ranges), and (3) Pairs of attribute-value to be tested (e.g., specific Capability-value pairs). If the coverage is not okay, then we jump to Step 2. In the other case, Step 4 is triggered.

[0137] Step 4: If the coverage is okay, the module determines and replaces the timestamp and location in the generated indistinguishable behavior with the timestamps and locations of testing probes that represent the closest match. This can be done using the Linear assignment problem using Jonker-Volgenant algorithm.

[0138] Step 5: The module generates the probing message.

[0139] Step 6: The module stores the generated indistinguishable probing request messages.

[0140] Step 7: Then, if the agent side correspond to the prober side (the role tag is prober), the module determines the probing UEs to be used (either as source or as destination of the probes depending on the agent being at the UE-side or the Core-side)

[0141] Step 8: The module triggers the probe-sending process depending on UE side or Core side.

[0142] Figure 6 illustrates an example of probing UE generation using GAN.

[0143] In the first step, four different inputs are provided. As illustrated in Figure 6, the D-GAN first takes a seed and training data consisting of UE 1, 2 and 3 ’ s timestamps and locations as input to generate a list of records containing RRC UE state transition. As mentioned before, note that the training data can include more columns to capture the behavior of users using the UE devices.P111304W001In this example, only device id, timestamp, and location are shown. Each row consists of the device ID from which the probe needs to be sent, the timestamp and the location from which the requests need to be sent. For instance, in the first row, a probe will be sent from a device with ID 1 at timestamp 0 from location number 1. However, the capability -value pairs are missing from this GAN-generated list. Thus, a third input is used to augment this table to include capability-value pairs. The third input consists of a mapping of capability-values pairs and device ID. The device from which the probe needs to be sent at timestamp 0 has these capability-value pairs DelayBudgetReporting: S and ue-cat: 5. Next, this augmented list is compared with the list of capability-value pairs to be tested. It is noted that the one marked “green” is not covered by any of the devices in the output. That is why more data is generated until the D-GAN generates a dataset containing devices whose combination covers all given capability-value pairs to be tested. In the second iteration, D-GAN generates device ID 1,2,3 and 4. UE 1 supports the capability marked green whereas UE 2, UE 3 cover capabilities marked red and pink. Note that UE 4 also has a capability that is not desired to test, but that is okay. As long as no capability value pair that is wanted to test is missing, it is fine.

[0144] Reduction of the probing UEs using set cover algorithm: To minimize the overhead on the RAN, as few UEs as possible should be used. However, the UEs used must also be able to cover all the capability -value pairs. To meet both these constraints, the system can minimize the number of UEs generated by GAN in such a way that the subset of UEs can cover all the capabilityvalue pairs. The previous example gives a list of devices that cover all the capabilities to be tested, specifically, devices 1,2,3, and 4. Each of the devices covers a different set of capabilities. However, it is noted that the combination of devices 2 and 3 can cover all the capabilities. Device 4 is not mandatory. Hence, to minimize the number of devices, devices with ID 1 and 4 can be eliminated. The set cover algorithm is used to minimize the number of devices.

[0145] Mixing to-be-tested values with GAN-Generated values using LAPJV algorithm: Capability -value pairs is not the only thing to be tested. The users may also be interested in testing the RAN at particular time and from a particular location. However, if the GAN-generated timestamp and / or location are replaced with the values to be tested without any sophisticated techniques, the probes become distinguishable. A malicious RAN running clustering algorithms can easily isolate such probes. Therefore, to make the probes as indistinguishable as possible, theP111304W001LAPJV algorithm can be used. This algorithm merges values to be tested in such a way that the resulting probes are highly indistinguishable. In this final step, the system takes as an input the timestamps 0 and 900 at which the RAN is tested for anomalous behavior. It already has the timestamps generated by D-GAN. Device 1 must send the probe at 10, device 2 at 888, and device 3 at 970. Recall that in the motivating example, the GAN-generated timestamps were replaced with the timestamps at which it was suspected the RAN to misbehave. The LAPJV algorithm is used to find out which of the generated timestamps should be replaced such that the overall impact of this mixing is minimal. It first forms a bipartite graph between the timestamps to be tested and the timestamps generated by the GAN. Next, it calculates the difference between the value of two nodes connected by any given edge. This is known as the weight of the edge. Note that the graph formed does not have one-to-one mapping. The LAPJV algorithm gives a graph with a one-to-one mapping between the elements of both sets such that the sum of the weights of the selected edges is minimum. Once there is that one-to-one mapping, it can simply replace 10 with 0 and 888 with 900. This ensures the resulting series of timestamps at which the RAN will be tested will remain almost indistinguishable while including all the values that are wanted to be tested. If 970 was replaced with 0, and 10 with 900, the behavior would have been easily traceable since device 1 cannot be sending any requests around timestamp 900 and so is the case with the device.

[0146] Figure 7 illustrates an example workflow of the verification function. The verification module receives intercepted requests coming from the vRAN and matches its subscriber identity (IMSI) with that of all the probing UEs. If there is a match, the agent processes it further, otherwise discards it.

[0147] Step 1 : The module receives the intercepted request message related to one of the IMSIs of the probing UEs.

[0148] Step 2: The module identifies to which test the request message corresponds (e.g., UERadioCapability Infoindication received at the Core is related to the UE Radio capabilities test). If no test was identified, Step 3 is triggered. Otherwise, Step 4 executes.

[0149] Step 3: The module generates an alert on “Message injection Attack” as this message was not expected to be received from the probing UE.P111304W001

[0150] Step 4: The attributes to be tested (A test) are extracted from the intercepted request message and the attributes to be tested are retrieved from the probing requests generated earlier by the prober module (A_probe).

[0151] Step 5 : Compare each value in A test with the corresponding value in A_probe. If there is a full match (i.e., A test == A_probe), the process loops back to the next intercepted request message (Step 1). Else, Step 6 is triggered.

[0152] Step 6: The module generates an Alert about “Message Modification Attack”.

[0153] Step 7: In case of some request messages are not received after a certain threshold from the probing time, an Alert about “Message dropping Attack, is generated.

[0154] Accordingly, embodiments described herein provide methods performed by a network node operating in the core network of a communication network, and a wireless device / mobile device node communicating with a set of network devices served by this network node via a serving radio access node, for detecting a man-in-the-middle attacker located in between the network node and the served mobile devices.

[0155] The network node and the wireless device simultaneously generate the same set of indistinguishable probing requests messages using a generative ML method (e.g., deterministic GAN), taking as input a number of datasets, depending on the test case (e.g., attributes modification such as radio capabilities, 3GPP message injection or deletion, etc.), and the role of network node and the mobile device node with respect to the test case, each one being a prober or a verifier.

[0156] Responsive to the network node being a prober for this test case, the network node determines the IMSI of the devices to which the probes should be sent and then sends the generated probing request messages for this test case specifically with the IMSI corresponding to those network devices.

[0157] Responsive to the network node being a verifier for this test case, the network node intercepts the request message(s) received with IMSI corresponding to the network devices from which the probes should have been sent, and then verifies the received request message based on the generated probing requests for this test case.P111304W001

[0158] Responsive to the wireless device being a prober for this test case, the node determines the IMSI of the network devices to which the probes should be sent and instructs them (directly or indirectly) to send the generated probing request messages to the network node.

[0159] Responsive to the wireless device being a verifier for this test case, the node receives the request messages from the network node and then verifies each received request message based on the generated probing requests for this test case.

[0160] The network node and / or wireless device can then generate an alert identifying the attack type (injection, dropping, modification) of the test case related to the attack.

[0161] Figure 8 is a flow chart illustrating an example method performed by a network node. The network node can be any of the devices described herein including, for example, core network node 108, access node 110, UE 112, security (e.g. RANWatson) manager and / or security agent devices.

[0162] Step 180: The network node generates one or more probing request messages. The probing request message(s) can be generated according to any of the methods described herein, see Figures 5 and 6 for example. The probing request messages can be generated in accordance with one or more of: historical data, behavior aspects, UE parameters and / or capabilities, RRC state transition, etc. The probing request message(s) can be generated such that they are indistinguishable probing requests from normal UE signaling. A generative ML model can be used to generate the probing request messages. The probing message(s) can be generated to test for at least one of message modification attacks, message injection attacks, and / or message deletion attacks. The network node can store the generated probing request messages for later use (e.g. verification).

[0163] Step 182: The network node determines / identifies if it has the role of probing node. This can be based on configuration information and / or a received message assigning the role of prober or verifier.

[0164] Step 184: Responsive to the network node being identified as a prober for this test case, the network node determines the devices (e.g. by their IMSI) to which the probes should be sent. The network node then triggers the transmission of the probing request message(s), directly or indirectly, by sending the generated probing request messages or instructing them to send the generated probing request messages.P111304W001

[0165] Step 186: Responsive to the network node being identified as a verifier for the test case, the network node receives (e.g. intercepts) at least one request message(s) from the network device(s) from which the probes should have been sent.

[0166] Step 188: The network nodes verifies each received request message based on comparing it with the stored, generated probing requests for this test case. The verification process can be performed in accordance with one or more of the examples described with respect to Figure 7. This can include identifying whether the received message corresponds to a probing request message by matching a subscriber identity (e.g. IMSI) associated with the received message with probing node identities. The received message can be verified by comparing it with the generated at least one probing request message(s). Verification can include extracting attributes to be tested from the received message(s) and comparing the extracted attributes with corresponding expected attributes from the generated at least one probing request message.

[0167] In some embodiments, the network node can perform at least one action (e.g. send an alert) in response to the verification result. The alert can identify a type of man-in-the-middle attack selected from message modification attacks, message injection attacks, and message deletion attacks. The network node can generate an alert for message injection attack when the received message does not correspond to any expected probing request message and / or generate an alert for message deletion attack when an expected probing request message is not received within a predetermined time threshold.

[0168] It will be appreciated that one or more of the above steps can be performed simultaneously and / or in a different order. Also, steps illustrated in dashed lines are optional and can be omitted in some embodiments.

[0169] It will be appreciated that in some embodiments, a wireless device 112 can communicate (e.g. transmit / receive messages) directly with a network node such as core network node 108. In other embodiments, messages and signals between the entities may be communicated via other nodes, such as radio access node (e.g. gNB, eNB) 110.

[0170] Example embodiments include:

[0171] Al . A method performed by a network node, the method comprising: generating at least one probing request message for a test case; determining if the network node is the probing nodeP111304W001 for the test case; and responsive to determining that the network node is the probing node, triggering transmission of the generated at least one probing request message.

[0172] A2. The method of Al, wherein the network node is a wireless device.

[0173] A3. The method of Al, wherein the network node is a core network node.

[0174] A4. The method of Al to A3, wherein, responsive to determining that the network node is not the probing node, receiving at least one probing request message; and verifying the received at least one probing request message.

[0175] A5. The method of A4, wherein verifying includes comparing the at least one received probing request message to the generated at least one probing request message.

[0176] A6. The method of Al to A5, further comprising, performing at least one action in response to the verification result.

[0177] A7. A network node comprising a radio interface and processing circuitry configured to perform the methods of any of embodiments A1-A6.

[0178] Figure 9 shows a wireless device UE 200 in accordance with some embodiments. The UE 200 presents additional details of some embodiments of the UE 112 of Figure 1. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0179] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehi cl e-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 humanP111304W001 user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0180] The UE 200 includes processing circuitry 202 that is operatively coupled via a bus 204 to an input / output interface 206, a power source 208, a memory 210, a communication interface 212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in this figure. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0181] The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 210. The processing circuitry 202 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, the processing circuitry 202 may include multiple central processing units (CPUs).

[0182] In the example, the input / output interface 206 may be configured to provide an interface or interfaces to an input device, 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, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 200. 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 web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an opticalP111304W001 sensor, a proximity sensor, a biometric sensor, etc., 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.

[0183] In some embodiments, the power source 208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 208 may further include power circuitry for delivering power from the power source 208 itself, and / or an external power source, to the various parts of the UE 200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 208 to make the power suitable for the respective components of the UE 200 to which power is supplied.

[0184] The memory 210 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), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 210 includes one or more application programs 214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 216. The memory 210 may store, for use by the UE 200, any of a variety of various operating systems or combinations of operating systems.

[0185] The memory 210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 210 mayP111304W001 allow the UE 200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 210, which may be or comprise a device-readable storage medium.

[0186] The processing circuitry 202 may be configured to communicate with an access network or other network using the communication interface 212. The communication interface 212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers used to communicate, 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 218 and / or a receiver 220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0187] In the illustrated embodiment, communication functions of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing 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 networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0188] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports theP111304W001 sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0189] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0190] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot 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 electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 200.

[0191] As yet another specific example, in an loT scenario, 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. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3 GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipmentP111304W001 that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0192] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that 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 the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0193] Figure 10 shows a network node 300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), 0-RAN nodes or components of an 0-RAN node (e g., 0-RU, 0-DU, O-CU).

[0194] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an 0-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0195] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entitiesP111304W001(MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0196] The network node 300 includes a processing circuitry 302, a memory 304, a communication interface 306, and a power source 308. The network node 300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 304 for different RATs) and some components may be reused (e.g., a same antenna 310 may be shared by different RATs). The network node 300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 300.

[0197] The processing circuitry 302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 300 components, such as the memory 304, to provide network node 300 functionality.

[0198] In some embodiments, the processing circuitry 302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 may be onP111304W001 separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip or set of chips, boards, or units.

[0199] The memory 304 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 302. The memory 304 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 capable of being executed by the processing circuitry 302 and utilized by the network node 300. The memory 304 may be used to store any calculations made by the processing circuitry 302 and / or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated.

[0200] The communication interface 306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 306 comprises port(s) / terminal(s) 316 to send and receive data, for example to and from a network over a wired connection. The communication interface 306 also includes radio front-end circuitry 318 that may be coupled to, or in certain embodiments a part of, the antenna 310. Radio front-end circuitry 318 comprises filters 320 and amplifiers 322. The radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. The radio front-end circuitry 318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 320 and / or amplifiers 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 318.P111304W001The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0201] In certain alternative embodiments, the network node 300 does not include separate radio front-end circuitry 318, instead, the processing circuitry 302 includes radio front-end circuitry and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 312 is part of the communication interface 306. In still other embodiments, the communication interface 306 includes one or more ports or terminals 316, the radio front-end circuitry 318, and the RF transceiver circuitry 312, as part of a radio unit (not shown), and the communication interface 306 communicates with the baseband processing circuitry 314, which is part of a digital unit (not shown).

[0202] The antenna 310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 310 is separate from the network node 300 and connectable to the network node 300 through an interface or port.

[0203] The antenna 310, communication interface 306, and / or the processing circuitry 302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 310, the communication interface 306, and / or the processing circuitry 302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0204] The power source 308 provides power to the various components of network node 300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 300 with power for performing the functionality described herein. For example, the network node 300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an inputP111304W001 circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 308. As a further example, the power source 308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0205] Embodiments of the network node 300 may include additional components beyond those shown in this figure for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 300 may include user interface equipment to allow input of information into the network node 300 and to allow output of information from the network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 300. In some embodiments providing a core network node, such as core network node 108 of Figure 1, some components, such as the radio front-end circuitry 318 and the RF transceiver circuitry 312 may be omitted.

[0206] Figure 11 is a block diagram illustrating a virtualization environment 400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, 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 functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.P111304W001

[0207] Applications 402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0208] Hardware 404 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 408A and 408B (one or more of which may be generally referred to as VMs 408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 406 may present a virtual operating platform that appears like networking hardware to the VMs 408.

[0209] The VMs 408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 406. Different embodiments of the instance of a virtual appliance 402 may be implemented on one or more of VMs 408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0210] In the context of NFV, a VM 408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 408, and that part of hardware 404 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 408 on top of the hardware 404 and corresponds to the application 402.

[0211] Hardware 404 may be implemented in a standalone network node with generic or specific components. Hardware 404 may implement some functions via virtualization.P111304W001Alternatively, hardware 404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 410, which, among others, oversees lifecycle management of applications 402. In some embodiments, hardware 404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 412 which may alternatively be used for communication between hardware nodes and radio units.

[0212] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.P111304W001

[0213] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0214] The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description.P111304W001ABBREVIATIONSAt least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).3 GPP 3rd Generation Partnership Project 5G 5th Generation 6G 6thGeneration ABS Almost Blank Subframe ARQ Automatic Repeat Request AWGN Additive White Gaussian Noise BCCH Broadcast Control Channel BCH Broadcast Channel CA Carrier Aggregation CC Carrier Component CCCH SDU Common Control Channel SDU CDMA Code Division Multiplex Access CGI Cell Global Identity CIR Channel Impulse Response CP Cyclic Prefix CPICH Common Pilot Channel CQI Channel Quality Information C-RNTI Cell RNTI CSI Channel State Information DCCH Dedicated Control Channel DL Downlink DM Demodulation DMRS Demodulation Reference Signal DRX Discontinuous Reception DTX Discontinuous Transmission DTCH Dedicated Traffic Channel DUT Device Under Test E-CID Enhanced Cell-ID (positioning method) Ec / No Received energy per chip divided by the power density in the band eMBMS Evolved Multimedia Broadcast Multicast Services ECGI Evolved CGI eNB E-UTRAN NodeB ePDCCH Enhanced Physical Downlink Control Channel E-SMLC Evolved Serving Mobile Location Center E-UTRAN Evolved Universal Terrestrial Radio Access Network FDD Frequency Division Duplex FFS For Further StudyP111304W001 gNB Base station in NR GNSS Global Navigation Satellite System HARQ Hybrid Automatic Repeat Request HO Handover HSPA High Speed Packet Access HRPD High Rate Packet Data LOS Line of Sight LPP LTE Positioning Protocol LTE Long-Term Evolution MAC Medium Access Control MAC Message Authentication Code MBSFN Multimedia Broadcast Multicast Service Single Frequency Network MBSFN ABS MBSFN Almost Blank Subframe MDT Minimization of Drive Tests MIB Master Information Block MME Mobility Management Entity MSC Mobile Switching Center NPDCCH Narrowband Physical Downlink Control Channel NR New Radio OCNG OFDMA Channel Noise Generator OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OSS Operations Support System OTDOA Observed Time Difference of Arrival O&M Operation and Maintenance PBCH Physical Broadcast Channel P-CCPCH Primary Common Control Physical Channel PCell Primary Cell PCFICH Physical Control Format Indicator Channel PDCCH Physical Downlink Control Channel PDCP Packet Data Convergence Protocol PDP Power Delay Profile PDSCH Physical Downlink Shared Channel PGW Packet Gateway PHICH Physical Hybrid-ARQ Indicator Channel PLMN Public Land Mobile Network PMI Precoding Matrix Indicator PRACH Physical Random Access Channel PRS Positioning Reference Signal PSS Primary Synchronization Signal PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RACH Random Access Channel QAM Quadrature Amplitude Modulation RAN Radio Access NetworkP111304W001RAT Radio Access Technology REC Radio Link Control RLM Radio Link Monitoring RNC Radio Network Controller RNTI Radio Network Temporary Identifier RRC Radio Resource Control RRM Radio Resource Management RS Reference Signal RSCP Received Signal Code Power RSRP Reference Symbol Received Power ORReference Signal Received PowerRSRQ Reference Signal Received Quality ORReference Symbol Received QualityRS SI Received Signal Strength Indicator RSTD Reference Signal Time Difference SCH Synchronization Channel SCell Secondary Cell SDAP Service Data Adaptation Protocol SDU Service Data Unit SFN System Frame Number SGW Serving Gateway SI System Information SIB System Information Block SNR Signal to Noise Ratio SON Self-Organizing Network ss Synchronization Signal sss Secondary Synchronization Signal TDD Time Division Duplex TDOA Time Difference of Arrival TOA Time of Arrival TSS Tertiary Synchronization Signal TTI Transmission Time Interval UE User Equipment UL Uplink UMTS Universal Mobile Telecommunications System USIM Universal Subscriber Identity Module UTDOA Uplink Time Difference of Arrival WCDMA Wideband CDMA WLAN Wireless Local Area Network

Claims

P111304W001CLAIMS1. A method performed by a network node configured to perform a probing function, the method comprising: generating at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages; determining that the network node is a probing node for the test case; and responsive to determining that the network node is the probing node, triggering transmission of the generated at least one probing request message through a radio access network.

2. The method of claim 1, wherein the network node is a wireless device.

3. The method of claim 1, wherein the network node is a core network node.

4. The method of any one of claims 1 to 3, wherein generating the at least one probing request message comprises using historical data including behavior aspects of user equipment based on at least one of user equipment communication parameters and radio resource control state transitions.

5. The method of claim 4, wherein the user equipment communication parameters include at least one of a radio capability, a data rate capability, a supported frequency band, an inactive state parameter, and a maximum downlink data rate parameter.

6. The method of claim 4, wherein the radio resource control (RRC) state transitions include transitions between RRC ACTIVE, RRC INACTIVE, and RRC IDLE states corresponding to user equipment registration and connection management states.

7. The method of any one of claims 1 to 6, wherein the generative machine learning model is a deterministic generative adversarial network that generates identical probing request messages at both the probing node and a verification node using a same seed value and same historical data.

8. The method of claim 7, wherein the deterministic generative adversarial network takes as input the seed value and historical data consisting of the user equipment communication parameters.P111304W0019. The method of any one of claims 7 to 8, wherein the historical data includes at least one of: a device identifier, a timestamps, and a location from which probing requests should be sent.

10. The method of any one of claims 7 to 9, wherein the generative machine learning model further comprises using a linear assignment problem algorithm to replace generated timestamps and locations with timestamps and locations for testing probes that represent a closest match.

11. The method of claim 10, wherein the linear assignment problem algorithm is a Jonker- Volgenant algorithm that forms a bipartite graph between generated values and values to be tested to minimize distinguishability of resulting probes.

12. The method of any one of claims 1 to 11, wherein the at least one probing request message is generated to test for at least one of message modification attacks, message injection attacks, and message deletion attacks.

13. The method of any one of claims 1 to 12, wherein triggering transmission includes determining devices by their international mobile subscriber identity to which the at least one probing request message should be sent.

14. The method of any one of claims 1 to 13, further comprising, storing the generated at least one probing request message for later verification.

15. A network node configured to perform a probing function, the network node comprising a radio interface and processing circuitry and configured to: generate at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages; determine that the network node is a probing node for the test case; and responsive to determining that the network node is the probing node, trigger transmission of the generated at least one probing request message through a radio access network.

16. The network node of claim 15, wherein the network node is a wireless device.

17. The network node of claim 15, wherein the network node is a core network node.

18. The network node of any one of claims 15 to 17, wherein generating the at least one probing request message comprises using historical data including behavior aspects of user equipmentP111304W001 based on at least one of user equipment communication parameters and radio resource control state transitions.

19. The network node of claim 18, wherein the user equipment communication parameters include at least one of: a radio capability, a data rate capability, a supported frequency band, an inactive state parameter, and a maximum downlink data rate parameter.

20. The network node of claim 18, wherein the radio resource control (RRC) state transitions include transitions between RRC ACTIVE, RRC INACTIVE, and RRC IDLE states corresponding to user equipment registration and connection management states.

21. The network node of any one of claims 15 to 20, wherein the generative machine learning model is a deterministic generative adversarial network that generates identical probing request messages at both the probing node and a verification node using a same seed value and same historical data.

22. The network node of claim 21, wherein the deterministic generative adversarial network takes as input the seed value and historical data consisting of the user equipment communication parameters.

23. The network node of any one of claims 21 to 22, wherein the historical data includes at least one of: a device identifier, a timestamp, and a location from which probing requests should be sent.

24. The network node of any one of claims 21 to 23, wherein the generative machine learning model further comprises using a linear assignment problem algorithm to replace generated timestamps and locations with timestamps and locations for testing probes that represent a closest match.

25. The network node of claim 24, wherein the linear assignment problem algorithm is a Jonker-Volgenant algorithm that forms a bipartite graph between generated values and values to be tested to minimize distinguishability of resulting probes.

26. The network node of any one of claims 15 to 25, wherein the at least one probing request message is generated to test for at least one of message modification attacks, message injection attacks, and message deletion attacks.P111304W00127. The network node of any one of claims 15 to 26, wherein triggering transmission includes determining devices by their international mobile subscriber identity to which the at least one probing request message should be sent.

28. The network node of any one of claims 15 to 27, further comprising, storing the generated at least one probing request message for later verification.

29. A method performed by a network node configured to perform a verification function, comprising: generating at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages; determining that the network node is a verification node for the test case; receiving a first message from a radio access network; identifying whether the received first message corresponds to a probing request message by matching a subscriber identity associated with the first message with probing node identities; and responsive to identifying that the received first message corresponds to a probing request message, verifying the first message by comparing the received first message with the generated at least one probing request message.

30. The method of claim 29, wherein the network node is a wireless device.

31. The method of claim 29, wherein the network node is a core network node.

32. The method of any one of claims 29 to 31, wherein responsive to determining that the network node is the verification node, storing the generated at least one probing request message for later verification.

33. The method of any one of claims 29 to 32, wherein the subscriber identity is an international mobile subscriber identity.

34. The method of any one of claims 29 to 33, wherein verifying further comprises extracting attributes to be tested from the received first message and comparing the extracted attributes with corresponding expected attributes from the generated at least one probing request message.P111304W00135. The method of claim 34, wherein the expected attributes of the received first message are generated using a generative machine learning model with the same seed value and historical data used to generate the at least one probing request message.

36. The method of claim 35, wherein the generative machine learning model is a deterministic generative adversarial network.

37. The method of claim 36, wherein the deterministic generative adversarial network generates identical expected attributes at both a probing node and the verification node using a same seed value and historical data.

38. The method of claim 34, wherein the attributes include user equipment communciation parameters.

39. The method of any one of claims 29 to 38, further comprising, generating an alert in response to a verification result.

40. The method of claim 39, wherein the alert identifies a type of man-in-the-middle attack selected from message modification attack, message injection attack, and message deletion attack.

41. The method of claim 39, further comprising, generating an alert for message injection attack when the received first message does not correspond to any expected probing request message.

42. The method of claim 39, further comprising, generating an alert for message deletion attack when an expected probing request message is not received within a predetermined time threshold.

43. A network node configured to perform a verification function, the network node comprising a radio interface and processing circuitry and configured to: generate at least one probing request message for a test case using a generative machine learning model, wherein the at least one probing request message is generated to be indistinguishable from normal signaling messages; determine that the network node is a verification node for the test case; receive a first message from a radio access network; identify whether the received first message corresponds to a probing request message by matching a subscriber identity associated with the first message with probing node identities; andP111304W001 responsive to identifying that the received first message corresponds to a probing request message, verifying the first message by comparing the received first message with the generated at least one probing request message.

44. The network node of claim 43, wherein the network node is a wireless device.

45. The network node of claim 43, wherein the network node is a core network node.

46. The network node of any one of claims 43 to 45, wherein responsive to determining that the network node is the verification node, storing the generated at least one probing request message for later verification.

47. The network node of any one of claims 43 to 46, wherein the subscriber identity is an international mobile subscriber identity.

48. The network node of any one of claims 43 to 47, wherein verifying further comprises extracting attributes to be tested from the received first message and comparing the extracted attributes with corresponding expected attributes from the generated at least one probing request message.

49. The network node of claim 48, wherein the expected attributes of the received first message are generated using a generative machine learning model with the same seed value and historical data used to generate the at least one probing request message.

50. The network node of claim 49, wherein the generative machine learning model is a deterministic generative adversarial network.

51. The network node of claim 50, wherein the deterministic generative adversarial network generates identical expected attributes at both a probing node and the verification node using a same seed value and historical data.

52. The network node of claim 48, wherein the attributes include user equipment communciation parameters.

53. The network node of any one of claims 43 to 52, further configured to generate an alert in response to a verification result.P111304W00154. The network node of claim 53, wherein the alert identifies a type of man-in-the-middle attack selected from message modification attack, message injection attack, and message deletion attack.

55. The network node of claim 53, further configured to generate an alert for message injection attack when the received first message does not correspond to any expected probing request message.

56. The network node of claim 53, further configured to generate an alert for message deletion attack when an expected probing request message is not received within a predetermined time threshold.

Images