Unified management and monitoring of IoT nodes with multiple network connections

In one embodiment, a device receives data regarding a node from a plurality of management platforms, each management platform being associated with a different access network used by the node. The device applies a unified data model to the data regarding the node received from the plurality of management platforms, to form unified data regarding the node. The device analyzes the unified data regarding the node, to generate insight information. The device provides the insight information to an application associated with a manufacturer of the node.

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, more particularly, to unified management and monitoring of Internet of Things (IoT) nodes with multiple network connections.

BACKGROUND

An emerging area of interest in the field of computer networking is the “Internet of Things” (IoT), which may be used by those in the art to refer to uniquely identifiable objects/things and their virtual representations in a network-based architecture. In particular, the next frontier in the evolution of the Internet is the ability to connect more than just computers and communications devices, but rather the ability to connect “objects” in general, such as lights, appliances, vehicles, window shades and blinds, doors, locks, etc.

In recent years, the management of IoT nodes has also become increasingly complex, with some enterprises now managing millions of IoT nodes at the same time. Indeed, many IoT nodes are now configured to communicate via multiple connectivity types (e.g., Wi-Fi, V2X, cellular, etc.) and across multiple networks (e.g., different cellular providers, etc.). This helps to ensure that an IoT node is able to maintain connectivity under different conditions, such as geographic location, network outages, etc. Thus, the IoT node is able to report its telemetry to a collector, reliably. Autonomous vehicles, for instance, are projected to generate between 1.4 TB and 19 TB per hour of operation. Federal and state laws are also increasingly requiring the storage and analysis of sensor data relevant to an event and to facilitate autonomous data sharing.

In addition to the telemetry data itself, the amount data being transmitted by any IoT node may be of interest. For instance, a vehicle manufacturer may want to track and assess the data usage of each of its vehicles. However, since the data usage may be spread across different connectivity types and networks, this makes it extremely challenging to review and manage assets at the individual vehicle level.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

According to one or more embodiments of the disclosure, a device receives data regarding a node from a plurality of management platforms, each management platform being associated with a different access network used by the node. The device applies a unified data model to the data regarding the node received from the plurality of management platforms, to form unified data regarding the node. The device analyzes the unified data regarding the node, to generate insight information. The device provides the insight information to an application associated with a manufacturer of the node.

Description

In various embodiments, computer networks may include an Internet of Things network. Loosely, the term “Internet of Things” or “IoT” (or “Internet of Everything” or “IoE”) refers to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. In particular, the IoT involves the ability to connect more than just computers and communications devices, but rather the ability to connect “objects” in general, such as lights, appliances, vehicles, heating, ventilating, and air-conditioning (HVAC), windows and window shades and blinds, doors, locks, etc. The “Internet of Things” thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., via IP), which may be the public Internet or a private network.

Often, IoT networks operate within a shared-media mesh networks, such as wireless or PLC networks, etc., and are often on what is referred to as Low-Power and Lossy Networks (LLNs), which are a class of network in which both the routers and their interconnect are constrained. That is, LLN devices/routers typically operate with constraints, e.g., processing power, memory, and/or energy (battery), and their interconnects are characterized by, illustratively, high loss rates, low data rates, and/or instability. IoT networks are comprised of anything from a few dozen to thousands or even millions of devices, and support point-to-point traffic (between devices inside the network), point-to-multipoint traffic (from a central control point such as a root node to a subset of devices inside the network), and multipoint-to-point traffic (from devices inside the network towards a central control point).

Fog computing is a distributed approach of cloud implementation that acts as an intermediate layer from local networks (e.g., IoT networks) to the cloud (e.g., centralized and/or shared resources, as will be understood by those skilled in the art). That is, generally, fog computing entails using devices at the network edge to provide application services, including computation, networking, and storage, to the local nodes in the network, in contrast to cloud-based approaches that rely on remote data centers/cloud environments for the services. To this end, a fog node is a functional node that is deployed close to fog endpoints to provide computing, storage, and networking resources and services. Multiple fog nodes organized or configured together form a fog system, to implement a particular solution. Fog nodes and fog systems can have the same or complementary capabilities, in various implementations. That is, each individual fog node does not have to implement the entire spectrum of capabilities. Instead, the fog capabilities may be distributed across multiple fog nodes and systems, which may collaborate to help each other to provide the desired services. In other words, a fog system can include any number of virtualized services and/or data stores that are spread across the distributed fog nodes. This may include a master-slave configuration, publish-subscribe configuration, or peer-to-peer configuration.

FIG. 1Ais a schematic block diagram of an example simplified communication network100illustratively comprising nodes/devices at various levels of the network, interconnected by various methods of communication. For instance, the links may be wired links or shared media (e.g., wireless links, PLC links, etc.) where certain nodes, such as, e.g., routers, sensors, computers, etc., may be in communication with other devices, e.g., based on connectivity, distance, signal strength, current operational status, location, etc.

Specifically, as shown in the example network100, three illustrative layers are shown, namely a cloud layer, a fog layer, and an IoT device/node layer. Illustratively, a cloud layer110may comprise general connectivity via the Internet112, and may include one or more data centers114with one or more centralized servers116or other devices, as will be appreciated by those skilled in the art. Within the fog layer120, various fog nodes122may execute various fog computing resources on network edge devices, as opposed to datacenter/cloud-based servers or on the endpoint nodes132themselves of the IoT device layer130. Data packets (e.g., traffic and/or messages sent between the devices/nodes) may be exchanged among the nodes/devices of the computer network100using predefined network communication protocols such as certain known wired protocols, wireless protocols, PLC protocols, or other shared-media protocols where appropriate. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

Those skilled in the art will understand that any number of nodes, devices, links, etc. may be used in the computer network, and that the view shown herein is for simplicity. Also, those skilled in the art will further understand that while the network is shown in a certain orientation, the network100is merely an example illustration that is not meant to limit the disclosure.

FIG. 1Billustrates an example vehicle communication system140, according to various embodiments. In particular, vehicle communication system140may include any or all of the following components: a vehicle160, a transceiver150(e.g., a cellular tower, a roadside unit, another vehicle, etc.), and/or a remote supervisory service170. Generally, vehicle160may be any form of vehicle configured to move from one physical location to another such as, but not limited to, cars, buses, trucks, boats, trains, aerial vehicles, and the like. In many cases, vehicle160may be configured to transport people and/or cargo. Further, vehicle160may be an autonomous vehicle, semi-autonomous vehicle, or manually-operated vehicle, according to the various embodiments herein.

In some embodiments, vehicle communication system140may be a specific implementation of communication network100. Notably, supervisory service170may be implemented at the cloud layer110, such as at a particular server116in a data center114or, alternatively, across multiple servers116, such as part of a cloud-based service. Similarly, transceiver150may be a fog node122at fog layer120, while vehicle160may be viewed as an IoT node132at IoT device layer130. Thus, vehicle160may communicate directly with transceiver150, and/or via other IoT nodes132(e.g., other vehicles, etc.), and transceiver150may provide some degree of processing over the communicated data.

Transceiver150may communicate with supervisory service170via a WAN, such as the Internet112or another WAN. For example, transceiver150may communicate with supervisory service170by leveraging a hardwired network connection, cellular or other wireless connection, satellite connection, or the like. Communications between vehicle160and transceiver150may generally be wireless and use any form of known wireless communication (e.g., Wi-Fi, cellular, light-based, etc.). In some implementations, vehicle160may include communication equipment that allows vehicle160to leverage different network connections, such as different cellular carrier networks, to ensure that vehicle160remains connected to supervisory service170as it travels.

As would be appreciated, vehicle160may comprise its own local network, to allow the various components of vehicle160to communicate with one another. For example, vehicle160may comprise any number of sub-networks, such as a Controller Area Network (CAN) bus, an IP network, etc., to allow the various systems of vehicle160to communicate with one another. Such system may include, but are not limited to, an engine control unit (ECU), a battery management system (BMS) that manages the local battery of vehicle160, an advanced driver assistance system (ADAS) system, and the like. A local gateway of vehicle160may provide communicative connectivity between the local network of vehicle160and other devices. For example, the local gateway of vehicle160may provide wireless connectivity to transceiver150located along road166on which vehicle160is traveling. In some embodiments, vehicle160may also communicate directly with supervisory service170via the Internet112or another WAN, such as by leveraging a wireless connection to a cellular or satellite-based network.

FIG. 2is a schematic block diagram of an example computing device200(e.g., an apparatus) that may be used with one or more embodiments described herein e.g., as any of the devices shown inFIGS. 1A-1Babove (e.g., to provide supervisory service170, etc.) or any of the devices described further below. The device may comprise one or more network interfaces210(e.g., wired, wireless, cellular, PLC, etc.), at least one processor220, and a memory240interconnected by a system bus250, as well as a power supply260(e.g., battery, plug-in, etc.).

The one or more network interfaces210contain the mechanical, electrical, and signaling circuitry for communicating data over links coupled to the network100. The network interfaces may be configured to transmit and/or receive data using a variety of different communication protocols. Note, further, that the nodes may have two or more different types of network connections, e.g., wireless and wired/physical connections, and that the view herein is merely for illustration. Also, while the one or more network interfaces210are shown separately from power supply260, for fog modules using PLC, a network interface may communicate through the power supply260, or may be an integral component of the power supply. In some specific configurations the PLC signal may be coupled to the power line feeding into the power supply.

The memory240comprises a plurality of storage locations that are addressable by the processor220and the one or more network interfaces210for storing software programs and data structures associated with the embodiments described herein. The processor220may comprise hardware elements or hardware logic adapted to execute the software programs and manipulate the data structures245. An operating system242, portions of which are typically resident in memory240and executed by the processor, functionally organizes the device by, among other things, invoking operations in support of software processes and/or services executing on the device. These software processes and/or services may comprise an illustrative unified node management process248, as described herein.

The performance of a machine learning model can be evaluated in a number of ways based on the number of true positives, false positives, true negatives, and/or false negatives of the model. For example, the false positives of the model may refer to the number of times the model incorrectly flagged data usage as being abnormal. Conversely, the false negatives of the model may refer to the number of times the model incorrectly flagged data usage as normal. True negatives and positives may refer to the number of times the model correctly predicted whether the data usage was normal or abnormal, respectively. Related to these measurements are the concepts of recall and precision. Generally, recall refers to the ratio of true positives to the sum of true positives and false negatives, which quantifies the sensitivity of the model. Similarly, precision refers to the ratio of true positives the sum of true and false positives.

As noted above, many IoT nodes (e.g., vehicles, sensors, actuators, etc.) are new capable of communicating via multiple connectivity types and across multiple access networks. For instance, an IoT node may be configured to communicate using Wi-Fi, vehicle-to-vehicle (V2V) communications, vehicle-to-everything (V2X) communications, cellular via one or more subscriber identity modules (SIMs), which may take the form of traditional SIM cards, embedded SIMs (eSIMs), integrated SIMs (iSIMs), etc. (collectively referred to herein as “SIMs”), satellite, combinations thereof, or the like. Similarly, an IoT node may communicate across multiple access networks, such as cellular networks from different providers/mobile network operators (MNOs), satellite networks, land-based networks, etc.

Utilizing multiple connectivity types across multiple access networks helps to ensure that an IoT node is able to maintain connectivity under different conditions, such as geographic location, network outages, etc. Thus, the IoT node is able to report its telemetry to a collector, reliably. For instance, if a vehicle leaves the coverage range of a first cellular network, it may switch to communicating via a second cellular network. Indeed, autonomous vehicles are projected to generate between 1.4 TB and 19 TB per hour of operation, requiring persistent network connectivity. Federal and state laws are also increasingly requiring the storage and analysis of sensor data relevant to an event and to facilitate autonomous data sharing.

In addition to the telemetry data itself, the amount of data being transmitted by any IoT node may be of interest. For instance, an original equipment manufacturer (OEM) of a vehicle may want to track and assess the data usage of each of its vehicles. However, since the data usage may be spread across different connectivity types and networks, this makes it extremely challenging to review and manage assets at the individual vehicle level.

Unified Management & Monitoring of IoT Nodes with Multiple Network Connections

The techniques herein introduce an architecture for a unified management and monitoring system for IoT nodes with multiple connectivity types, such as connected vehicles. The unified architecture allows OEMs and other interested parties to manage and monitor the connections, detect anomalous behaviors at the vehicle level, perform diagnostics, segment traffic, automatically select connectivity, and/or perform testing.

Specifically, according to one or more embodiments of the disclosure as described in detail below, a device receives data regarding a node from a plurality of management platforms, each management platform being associated with a different access network used by the node. The device applies a unified data model to the data regarding the node received from the plurality of management platforms, to form unified data regarding the node. The device analyzes the unified data regarding the node, to generate insight information. The device provides the insight information to an application associated with a manufacturer of the node.

Operationally,FIG. 3illustrates an example300of vehicle160, which may employ a dual SIM, dual MNO deployment. More specifically, vehicle160may be equipped with two SIMs: 1.) a first SIM302athat allows vehicle160to communicate via a first MNO and 2.) a second SIM302bthat allows vehicle160to communicate via a second MNO. For instance, vehicle160may use SIM302ato send and/or receive telematics data, such as from various sensors of vehicle160(e.g., LIDAR sensors, temperature sensors, etc.). Conversely, vehicle160may use SIM302bto send and/or receive infotainment data.

As a result of the use of multiple SIMs (e.g., SIMs304a-304b), there may be a set of characteristics304of vehicle160spread across the various MNOs utilized by vehicle160, the OEM of vehicle160, etc. For instance, vehicle160may have a particular identifier (e.g., VehID999), vehicle identification number (VIN) (e.g., ABCDE12345), Manufacturer (e.g., Y), Model (e.g., Z), build year (e.g., 2019), country of origin (e.g., USA), electronic control unit (ECU) version (e.g., ECU-V-10.9.1.5). In addition, each SIM used by vehicle160may have its own characteristics. For instance, SIM302amay have a unique identifier (e.g., 1234567890), be associated with a particular MNO (e.g., MNO A), have an active or inactive state (e.g., Active), operate under a particular rate plan (e.g., Rate Plan MNO A), and have a data limit per cycle (e.g., 150 MB). Similarly, SIM302bmay have a unique identifier (e.g., 9876543210), be associated with a particular MNO (e.g., MNO B), have an active or inactive state (e.g., Active), operate under a particular rate plan (e.g., Rate Plan MNO B), and have a data limit per cycle (e.g., 650 MB).

While many or all of characteristics304of vehicle160may be known to its OEM or other interested party, further information about vehicle160. For instance, many MNOs maintain their own connectivity management platforms (CMPs), meaning that information such as data usage is only available to the OEM via these platforms. Thus, a unified monitoring and management view of vehicle160is not available, meaning that the OEM must mange each of SIMs302a-302bindividually. In addition, behavioral issues, such as behavioral anomalies, may not be readily identifiable using the information available from any given CMP.

FIG. 4illustrates an example architecture400for the unified management and monitoring of a node with multiple network connections, according to various embodiments. As shown, architecture400may be used to implement unified node management process248, allowing its executing device (e.g., device200) to perform the techniques herein. As would be appreciated, architecture400may be implemented on a single executing device or in a distributed manner across any number of devices. In the latter case, the combination of executing devices may be viewed as a singular device for purposes of performing the techniques herein.

In general, architecture400allows unified node management process248to provide a unified management and monitoring service to OEM application and information technology (IT) layer402, thereby unifying the various management platform418associated with the access networks used by the IoT node manufactured by the OEM. For instance, a vehicle manufacturer may maintain its own application for the management of its IoT nodes, but be limited in its ability to pull information from the various providers whose access networks the IoT nodes utilize. To do so, unified node management process248may offer a set of common APIs404, allowing layer402at the OEM to communicate with the management service provided by unified node management process248.

As noted previously, an IoT node may be configured to communicate via multiple connectivity types across multiple access networks. Consequently, information about the node may be spread across multiple management platforms, such as platform418a(CMP MNO A), platform418b(CMP MNO B), platform418c(CMP MNO C), etc., through an nthplatform418n(e.g., a non-cellular access management platform).

To communicate with each of management platforms418a-418n, architecture400may include an adapter layer414. More specifically, adapter layer414may include corresponding adapters416a,416b,416c, through416nfor each of management platforms418a-418n. Each adapter416may allow unified node management process248to retrieve data from the corresponding management platform418(e.g., by issuing queries, for data regarding the IoT node, etc.) and/or pass instructions to the corresponding management platform418(e.g., by changing a configuration for the node, etc.). In some instances, a management platform418may push information to adapter layer414without a corresponding adapter416first issuing a query for the information. Typically, each adapter416may be implemented to leverage application programming interfaces (APIs) of the corresponding management platform418.

By way of example, adapter layer414may receive any or all of the following information from the management platforms418:Data usage information—e.g., the amount of data transmitted and/or received by the IoT node via the access network associated with the management platform.Timing information—e.g., timestamp information for the data usage information. In some instances, the data usage information and timing information may be represented as a timeseries.Rate plan information—e.g., the name of the rate plan provided by the operator of the access network, the amount of data permitted by the plan (e.g., daily, weekly, monthly, or yearly data limit, etc.), whether data overages pricing information, and the like.Traffic information—e.g., the types of applications associated with the traffic of the IoT node (e.g., telemetry, infotainment, etc.).Configuration information—e.g., the connectivity type used by the IoT node to communicate via the access network (e.g., an eSIM, etc.), an identifier for the SIM, carrier settings, etc.

According to various embodiments, architecture400may also include a unified data model412that unified node management process248may apply to the data about the IoT node obtained using adapter layer414. Indeed, each management platform418may use different data formats, units of measure, or the like. For instance, one management platform418may provide data usage metrics on an hourly scale (e.g., an average of the data usage by the node over a given hour), while another management platform418may provide data usage metrics on a daily scale (e.g., the average data usage by the device over a given day). In another example, one management platform418may provide data usage metrics for the node in MB, while another management platform418may provide data usage metrics for the node in GB or even TB.

In further embodiments, unified node management process248may data model412to perform any number of data transformations on the data regarding the IoT node obtained via adapter layer414. For instance, to maintain a unified view of the IoT node, unified node management process248may aggregate the data usage metrics regarding the node obtained from the plurality of management platforms418, compute any number of statistics for the metrics (e.g., distributions, mean, median, max, min, etc.). Example languages that can be used to implement unified data model412may include, but are not limited to, the extensible markup language (XML), JavaScript Object Notation, or the like.

Architecture400may also include a services layer408that applies any number of services to the unified data regarding the node and/or allows for the unified management of management platforms418via unified node management process248, in some embodiments. For instance, as shown, services layer408may include any or all of the following services:eSiM Flex—this service may provide a single, simplified service to integrate service providers to architecture400and manage eSIMs used by IoT nodes managed and monitored by unified node management process248. Indeed, a key advantage of eSIMs is the ability to remotely reprogram them, which can be managed via the eSIM Flex service. For instance, eSIM Flex service may allow a user to active an eSIM EID to their carrier of choice, while allowing the OEM to maintain a separate eIM EID for telematics data.Smart FOTA—this service may be responsible for managing and sending firmware over the air (FOTA) updates to IoT nodes managed by unified node management process248. For instance, the Smart FOTA service may identify appropriate times to push firmware updates (e.g., during times of low node usage or transmissions) and schedule firmware updates, accordingly.App Velocity Suite—this service may provide a suite of utilities to maximize user experience with any application. For instance, this suite may attempt to optimize resource utilization and other network parameters, to ensure that certain application traffic meets its service level agreements (SLAs).E2E Monitoring—this service may provide end-to-end monitoring of a particular application in terms of its performance. For instance, App Dynamics by Cisco Systems, Inc., or another suitable application performance monitoring (APM) solution, may be used to provide this service.Data Compression & Encryption—in some instances, this service may be used to compress and/or encrypt information regarding a particular IoT node. This can be performed between unified node management process248and an external application (e.g., an OEM application) and/or between unified node management process248and any or all of management platforms418.Traffic Classification—this service may operate to classify the various types of network traffic sent to, and from, a given IoT node. For instance, this service may seek to identify the applications associated with the traffic, if not already known, their SLAs, and the like.Policy Builder & Orchestrator—this service may allow a user to define policies for the use of the information obtained regarding a node, such as security policies. In this instance, architecture400may include an automation & policy orchestration service420that enforces such a policy within architecture400. For example, one policy may permit or limit access to specific groups/resources within the OEM. In further embodiments, this service may provide network level security policies, as opposed to relying solely on application level access control. In another embodiment, this service may afford an OEM user with the ability to configure and set different data, streams that would span all connectivity units and types for a given IoT node (e.g., by implementing traffic segmentation). This would allow the OEM to understand the total data consumption for a given node, as well as the breakdown of that usage.Traffic Filtering—this service may apply filtering to traffic from the IoT node. For instance, this service may operate in conjunction with the other services in services layer408to apply security policies, perform traffic segmentation, and the like.Identity Management—this service may operate to provide note identity management across the various IoT nodes and applications that they may use. For instance, this service may take the form of the Identity Services Engine (ISE) by Cisco Systems, Inc., or another similar process. In general, this service may operate to identify individual IoT nodes, allowing various policies to be applied to them, such as traffic segmentation policies, access control policies, and the like.Connectivity Assurance—this service may generally be responsible for assessing and optimizing the performance of the various connectivity options available to a particular IoT node. Indeed, the general attributes of the network functions of a node may depend on its geographical location, rate plan, etc. In various embodiments, this service may determine the optimal connectivity medium for the node at any given time (e.g., for FOTA, certain types of traffic, etc.), based on factors such as the network congestion at surge hours per provider, location/coverage area of the node, priority of data type to be transferred (e.g., vehicle engine data vs. infotainment data).In one embodiment, this service may do so by obtaining call detail record (CDR) data (e.g., call set-up, duration of the call, amount of data transferred, etc.) for each IoT node. In turn, in one embodiment, this service may apply machine learning clustering to this data, to label the set {node, timespan, location, priority}. Once this service has collected sufficient datapoints from multiple nodes of the same type and from the same OEM, this service may employ a connectivity switch mechanism that allows the OEM application to switch the node(s) between connectivity mediums, thereby optimizing network performance with reduced data usage and/or cost.This service may also track and collect the transformation data for real and virtual connectivity units in a uniform way. By applying the machine learning algorithm, the service can learn the historical data and find a pattern for the transformation. In turn, the service can use the learned pattern to predict and recommend the usage of different real and/or virtual connectivity units of the IoT node.Automated Testing—another potential service at services layer408may be a service that allows for the automated testing of the connectivity management across multiple networks for a particular IoT node. In some instances, this service may automate user interface (UI) and/or API features of the connectivity management and allow for the automated validation of the security mechanisms described previously. For instance, this service may automatically validate any metadata provided by an OEM for a new IoT node. In further instances, this automation may also include functional testing, load testing, and/or integration testing across the various OEMs supported by unified node management process248.

According to various embodiments, architecture400may also include an analytics layer406that allows unified node management process248to perform various analytics on the unified data for the IoT nodes under its management and provide indications of this analysis to the OEM application at layer402via common APIs404.

In one embodiment, analytics layer406may assess the unified data for one or more of the IoT nodes, to generate data insights, at the individual node level or even globally. For instance, such insights may relate to roaming between access networks by the node, a trend in data consumption by the node, or a comparison of data consumption by the node to similar nodes, trends or patterns exhibited by nodes located within a certain geographical region, network performance information, or the like.

In another embodiment, analytics layer406may apply a machine learning-based anomaly detector to the unified data for a particular node, such as by comparing its behaviors to that of other, similar nodes. For instance, such a model may create a baseline of ‘normal’ data consumption by analyzing the data usage patterns of a particular type of IoT node from a particular OEM. In turn, this baseline can be used to identify when the data consumption of a given node deviates from this behavior by a statistically significant amount (e.g., through the use of one or more thresholds).

In a further embodiment, analytics layer406may also apply predictive analytics to the unified data for the IoT node(s), enabling the connectivity parameters of the nodes to be adjusted, in advance of failures or other issues. For instance, if a given node is predicted to lose connectivity soon with a particular MNO (e.g., based on prior nodes also losing connectivity at a certain location and/or time), this prediction can be used to switch the node to another MNO, proactively. In further cases, these predictions can be used to ensure that the SLAs of the traffic associated with the node are satisfied, by steering the traffic to the most appropriate connectivity types and/or networks.

Accordingly, architecture400may be configured to provide any or all of the following benefits:1. Node-centric connectivity management for multiple connectivity types—For instance, architecture400may provide a Vehicle/VIN centric connectivity management SaaS platform to vehicle OEMs, enabling global visibility and control OEMs across one or more connectivity types (e.g., SIMs, eSIMs, Wi-Fi, DSRC/C-V2X, etc.). With a vehicle or other IoT node as the central management entity, architecture400may maintain an extensible data model to store and manage OEM specific node metadata (e.g., VIN, year, brand, model, country, lifecycle, ECU IDs, firmware version, etc.).2. VIN-centric connectivity management across multiple networks architecture400may also provide a single pane of glass view for IoT nodes that have connectivity across multiple operator networks and afford connectivity management across global MNO platforms. Connectivity (e.g., voice, SMS, Data, etc.) can be managed across all networks from a single platform, such as cellular (4G/5G), Single/Dual SIMultiple eSIM profiles across MNOs DSRC/C-V2X, etc.3. eSIM management across telematics and consumer data—architecture400may further provide eSIM and traffic filtering capabilities. This may allow an OEM to define data segments (e.g., separating potential data streams such as telematics and autonomous vehicle data from consumer data such as streaming media or navigation). This may also allow a user of the IoT node to activate an eSIM EID to their carrier of choice, while allowing the OEM to maintain a separate eSIM EID for telematics data.4. Unified diagnostics across connectivity units—architecture400may further provide real time visibility into assessment of various health check points, such as rate plan, session info, data usage limit, vehicle state, etc., in a single network or across multiple networks. This may allow an OEM to fix connection issues by providing solutions dynamically over the network, such as increasing data usage limit, changing rate plan, providing ways to add new profiles from different network providers, switching between networks, etc. OEM users may also use the platform provided by architecture400to get a unified view of vehicles or other IoT nodes that are connected to various networks and fix various health check issues across networks.5. Anomaly detection and insights—as noted above, architecture400may also provide insights into node connectivity metrics pattern over a period of time. Architecture400may also automatically determine and set anomaly detection thresholds, to identify abnormal behaviors. This helps with finding data clusters for better troubleshooting of issues for node connectivity. The resulting insights can also help OEM to improve their solutions, proactively.6. Access control and network policy enforcement—nodes can be segmented through the identity service of architecture400and security policies enforced, to permit/limit access to specific groups/resources within the OEM. Indeed, by centralizing the identity management of the nodes, an OEM can apply security policies that are unique to each node segment to permit/limit access to specific groups/resources within their enterprise.7. Traffic segmentation—architecture400may also allow an OEM user to configure and set different data streams that would span all connectivity units and types for a given vehicle8. API orchestration—architecture400may further provides an OEM user with the ability to quickly integrate with various service providers, IoT platforms, CMPs, various internal OEM systems, and/or other external applications through an API orchestration service. This may be done by offering a unified data model across multiple systems, such as through a drag and drop API workflow builder. Doing so allows an OEM to quickly onboard new APIs and services without custom development work. The API orchestration by architecture400may also be augmented with OEM data such as connectivity information and node data, including node lifecycle and connectivity type lifecycle.9. Auto-selection of connectivity attributes and types—as noted above, architecture400may also automatically select and apply the best connectivity medium for a node, such as for particular traffic, FOTA, or across the board.10. Automated testing—the unified platform of architecture400can also automate the testing and validation of metadata, in a manner that can deal with the multi-tenancy of node management users. Indeed, architecture400can ensure global visibility for multiple OEMs using different connectivity types and using the APIs that may use dynamically created user and API key for each OEM, allowing architecture400to validate the data retrieved from OEMs for accuracy and the correct mapping of fields and format.

FIG. 5illustrates an example simplified500for the unified management of a node with multiple network connections, in accordance with one or more embodiments described herein. For example, a non-generic, specifically configured device (e.g., device200) may perform procedure500by executing stored instructions (e.g., process248). The procedure500may start at step505, and continues to step510, where, as described in greater detail above, the device may receive data regarding a node from a plurality of management platforms. In various embodiments, each management platform may be associated with a different access network used by the node. In one embodiment, the node comprises a vehicle equipped with two or more SIMs via which the vehicle communicates with two or more cellular access networks and the plurality of management platforms comprise two or more management platforms associated with the two or more cellular access network. In a further embodiment, the device receives the data regarding the node from a plurality of management platforms using a corresponding plurality of platform-specific connectors.

At step515, as detailed above, the device may apply a unified data model to the data regarding the node received from the plurality of management platforms, to form unified data regarding the node. For instance, in one embodiment, the device may aggregate data usage metrics regarding the node from a plurality of management platforms.

At step520, the device may analyze the unified data regarding the node, to generate insight information, as described in greater detail above. In one embodiment, the device may do so by applying a machine learning-based anomaly detector to the unified data. In another embodiment, the insight may be indicative of at least one of: roaming between access networks by the node, a trend in data consumption by the node, or a comparison of data consumption by the node to similar nodes.

At step525, as detailed above, the device may provide the insight information to an application associated with a manufacturer of the node. In one embodiment, the device may receive, via the application associated with the manufacturer of the node, an instruction to implement a change for the node comprising at least one of: adjusting a data usage limit of the node, changing a rate plan of the node, or adding a new profile for the node with an access network not previously used by the node. In turn, the device may implement the change for the node via one or more of the plurality of management platforms. In another embodiment, the device may implement traffic segmentation for traffic associated with the node, by sending instructions to the plurality of management platforms. For instance, the device may do so in response to an instruction to do so from the application associated with the manufacturer of the node. In addition, at least a portion of the traffic being segmented may comprises telemetry data generated by the node. In another embodiment, the device may apply clustering to the unified data regarding the node and that of a plurality of other nodes and control network access by the node, based in part on a result of the clustering. Procedure500then ends at step530.

While there have been shown and described illustrative embodiments for the unified management and monitoring of IoT nodes with multiple network connections, it is to be understood that various other adaptations and modifications may be made within the intent and scope of the embodiments herein. For example, while specific protocols are used herein for illustrative purposes, other protocols and protocol connectors could be used with the techniques herein, as desired. In addition, while certain anomaly detection models and parameters (e.g., thresholds) are shown, these models may be used on other forms of data and the parameters may be adjusted, as desired. Further, while the techniques herein are described as being performed by certain locations within a network, the techniques herein could also be performed at other locations, such as at one or more locations fully within the local network, etc.).