Patent Description:
Different types of IoT devices can have different data communication requirements. For example, some types of IoT devices can communicate a low amount of data, with a sporadic timing. Other types of IoT devices may communicate large amount of uplink, downlink, or bi-directional data during certain time intervals. If the IoT device type is known, the different communication requirements can be met, by assigning to the IoT device's traffic a channel having a Quality of Service (QoS) that guarantees meeting the requirements of that IoT device type.

However, conventional techniques for determining the IoT device type can have technical shortcomings, e.g., insufficient real-time accuracy in classification, that can render them unsuitable for selecting a QoS, or otherwise assigning channels or other resources.

Satellite communication systems can face particular factors, which can present technical challenges in assigning traffic the appropriate QoS. Example factors include scarcity of bandwidth, latency and potential packet loss. Also, in the context of assigning satellite link resources, incorrect assignments for IoT devices can have substantial costs additional to performance impact on the IoT device. More specifically, satellite link bandwidth can be expensive. Therefore, assigning a bandwidth to an IoT device that, for example, due to mis-identification of the device type, is greater than necessary can be costly.

Traffic from some IoT devices, such as health monitor devices or security systems, can be considered mission critical. Some of the smart IoT devices are always-on in nature, having sensors that capture users' offline activities and transmit information about activities, often to cloud services run by the device manufacturer.

Accordingly, what is needed is systems and methods for machine learning based classification of IoT device types, based on traffic fingerprint and without requiring deep packet inspection or decryption, the classification being accurate and real-time, for dynamic assignment of IoT device type-specific QoS and corresponding allocation of link resources.

<CIT> discloses an upstream resource allocation technique for satellite communications, including various channelization and frequency hopping techniques. A gateway performs allocation of time slots on upstream frequency channels to allow frequency hopping. A subscriber terminal may perform frequency hopping according to the allocation, and the range may be limited to the transition range of a digitally controlled oscillator unit at the subscriber terminal. A gateway allocates time slots on different upstream frequency channels in a prioritized manner. Subscriber terminals may receive the allocation, and then control the assignment of their upstream traffic to the time slots.

<CIT> discloses a finite state machine approach for capturing network telemetry to improve device classification. A device classification service receives a first set of telemetry data captured by one or more networking devices in a network regarding traffic associated with an endpoint device in the network. The service classifies the endpoint device as being of an unknown device type, by applying a machine learning-based classifier to the first set of telemetry data. The service instructs the one or more networking devices in the network to reset a finite state machine (FSM) of the traffic associated with the endpoint device. The device classification service receives a second set of telemetry data regarding traffic associated with the endpoint device and captured after reset of the FSM. The service reclassifies the endpoint device as being of a particular device type, by applying the machine learning-based classifier to the second set of telemetry data.

This Summary identifies examples of disclosed features and aspects. It is not an exclusive or exhaustive description of the disclosed subject matter. Additional features and aspects are described, and others will become apparent to persons skilled in the art upon reading the following detailed description and appended drawings that form a part thereof. Whether features or aspects are included in or omitted from this Summary is not intended as indicative of relative importance of such features.

Among examples of disclosed systems are implementations that can provide, among other features and aspects, fingerprint based detection and classification of Internet of Things (IoT) device types, adaptive allocation and access priority to link bandwidth, and various examples of such implementations can include a processor; and a memory, coupled to the processor, storing executable instructions that, when executed by the processor, can cause the processor to monitor a link traffic and generate a corresponding feature data, classify the device, based at least in part on applying a machine learning classifier to at least a portion of the feature data, between being and not being an IoT device of a particular IoT device type, and can cause the processor, in response to classifying the device as the IoT device of the particular IoT device type, to assign an IoT device type-specific QoS for carrying a traffic associated with the IoT device, and allocate, for traffic associated with the IoT device, resources of the link in accordance with the assigned IoT device type-specific QoS.

Among examples of disclosed systems are further implementations that can also include executable instructions that, when executed by the processor, can cause the processor to receive a baseline classifier model, store the baseline classifier model in a memory, and apply the stored baseline classifier model as the machine learning classifier. Examples of such implementations can also include, in the memory, executable instructions that, when executed by the processor, can cause the processor to generate a retrained baseline classifier model, based at least in part on applying a retraining to the stored baseline classifier; upload the retrained baseline classifier model to a server; and, subsequent to the upload, to receive an updated baseline classifier model, and set the stored baseline classifier model according to the received updated baseline classifier model.

Among examples of disclosed methods are implementations that can provide, among other features, fingerprint based detection of IoT devices, classification of IoT device type, and corresponding allocation of link resources, and various examples of such methods can include monitoring, in association with a link, a traffic of a device and generating a corresponding feature data; classifying the device, based at least in part on applying a machine learning classifier to at least a portion of the feature data, between being and not being an IoT device of a particular IoT device type; and in response to classifying the device as the IoT device of the particular IoT device type, assigning an IoT device type-specific QoS for carrying a traffic associated with the IoT device, and allocating, for traffic associated with the IoT device, resources of the link in accordance with the assigned IoT device type-specific QoS.

Among examples of disclosed methods are further implementations that can also include receiving a baseline classifier model, storing the baseline classifier model in a memory, and applying the stored baseline classifier model as the machine learning classifier. Various examples of such implementations can also include generating a retrained baseline classifier model, based at least in part on applying a retraining to the stored baseline classifier; uploading the retrained baseline classifier model to a server; and, subsequent to the upload, receiving an updated baseline classifier model, and setting the stored baseline classifier model according to the received updated baseline classifier model.

In the following detailed description, numerous specific details are set forth by way of examples to provide a thorough understanding of the disclosed subject matter. It may become apparent to persons of ordinary skill in the art, though, upon reading this disclosure, that one or more disclosed aspects may be practiced without such details. In addition, description of various example implementations according to this disclosure may include referencing of or to one or more known techniques or operations, and such referencing can be at relatively high-level, to avoid obscuring of various concepts, aspects and features thereof with details not particular to and not necessary for fully understanding the present disclosure.

Disclosed systems and methods according to this disclosure can provide traffic fingerprint based VSAT classifying of IoT device types, assigning IoT device type-specific QoS, and corresponding allocating of link resources and priority of access to link resources. Features of disclosed systems and methods can include, but are not limited to, real-time, accurate classification of IoT device type without deep packet inspection and regardless of encryption. In an aspect, the machine learning classifier can be implemented as a two-part or two-stage machine learning classifier that, based on device traffic, can first classify between an IoT device and a non-IoT device and then, if classified as an IoT devices, can classify the IoT device according to IoT device type. Secondary benefits of such features can include, for example, identification among different streaming devices, which can enable support of resolution conversion that is appropriate to the streaming device type - in addition to classifying IoT device types and corresponding allocating of link resources to IoT devices,.

Systems and methods according to the present disclosure can also provide server resource distribution of a centralized classifier model to a population of VSATs, e.g., hundreds of thousands of VSATs, for the VSATs to use in classifying IoT device types, assigning IoT device type-specific QoS, and allocating QoS appropriate link resources. Such systems and methods can also provide VSAT individual retraining of their respective copies of the centralized classifier model, uploading of their individual retraining results to the server resource, in addition to the server resource combining the uploaded individual retraining results into a new centralized classifier model. Features can also include the server resource conditioning distribution of the new centralized classifier model on passing one or more qualification tests. For purposes of description, disclosed machine learning classifiers associated with distribution of a centralized classifier model, VSAT individual retraining and uploading retraining results to the server, and server generation of a new centralized classifier based on the uploads, can be referred to as "federated learning classifier. " Training aspects of the federated learning classifier can be referred to as "federated machine learning training" or "federated ML training. " It will be understood that the phases "federated learning classifier," "federated machine learning training," "federated ML training," and variations thereof, are arbitrary names used herein solely for convenience of description and carry no intrinsic meaning.

<FIG> is a block schematic of one system for machine learning, traffic fingerprint based IoT device detection and type classification, and device type-based allocation and prioritization of access to VSAT inroute bandwidth (hereinafter "system <NUM>"). The system <NUM> can include an IoT server <NUM> that can connect through the Internet <NUM> and Internet interfacing P gateway (GW) <NUM> to a satellite GW <NUM>. The satellite GW <NUM> can include a radio frequency (RF) transmitter/receiver (TX/RX) <NUM> that can transmit an uplink <NUM> to a satellite resource <NUM> and receive from the satellite <NUM> a downlink <NUM>. The satellite resource <NUM> can repeat or re-transmit traffic received from the uplink <NUM>, over downlink <NUM> to an antenna (visible, but not separately numbered) coupled to VSAT RF transmitter/receiver (TX/RX) <NUM> of a VSAT terminal <NUM>. The VSAT terminal <NUM> can be associated, for example, with a premises <NUM> such as, without limitation, a customer home equipped and configured as a "smart home. " For purposes of description, the uplink <NUM> and downlink <NUM> will also be referenced, respectively, as "forward uplink <NUM>" and "forward downlink <NUM>. " The VSAT terminal RF TX/RX <NUM> can be configured to transmit a VSAT-to-satellite resource uplink <NUM> to the satellite resource <NUM> and receive the above-described forward downlink <NUM> from the satellite resource <NUM>. For purposes of description the VSAT-to-satellite resource uplink <NUM> will also be referred to as "reverse uplink" <NUM>.

The VSAT terminal <NUM> can include a satellite modem <NUM> that can connect at one side to the VSAT terminal TX/RX <NUM> and, at the other side, to a hub <NUM>. On the premises <NUM> and connected to the hub <NUM> by short range wireless or wired connection can be one or more IoT devices, such as the example first IoT device <NUM>-<NUM> and second IoT device <NUM>-<NUM> (collectively "IoT devices <NUM>"). Example type of IoT devices <NUM> can include, but are not limited to, cameras, light bulbs, health and well-being monitors, security devices, home appliance monitors, printer and consumer electronics. There can also be one or more non-IoT devices, such as the example first non-IoT device <NUM>-<NUM> and second non-IoT device <NUM>-<NUM> (collectively "non-IoT devices <NUM>," and labeled "NID" on <FIG>).

The VSAT terminal <NUM> can include a flow monitor <NUM>, an IoT device type classifier model <NUM>, and an IoT device type classifier machine learning (ML) training logic <NUM>. The flow monitor <NUM> can be configured to detect traffic traces, e.g., by monitoring a network tap in the hub <NUM>. The IoT device type classifier ML training logic <NUM> can be configured to analyze and characterize statistical attributes from the traffic traces. Examples of statistical attributes that can be characterized can include, but are not limited to, data rates and burstiness, activity cycles, and signaling patterns. A device behavior can be approximated using features extracted from the network traffic of the device. This can be used to generate training data. The IoT device type classifier ML training logic <NUM> can be configured to train the IoT device type classifier model <NUM> a machine learning model that can be used to detect similar device types. This approach is successful even when a device uses encrypted communication.

Using these attributes, techniques can be developed which not only distinguishes IoT from non-IoT traffic, but also identify specific IoT devices with a great degree of accuracy. The VSAT terminal <NUM> can also include an IoT device type-based QoS selection logic <NUM>. It will be understood that "QoS," as used in this description, includes but is not limited to latency, bandwidth, or packet loss, and any combination or sub-combination thereof.

Regarding wireless connection between IoT devices <NUM> and the hub <NUM>, example implementations can include Wi-Fi, or another wireless protocol, or various combinations or sub-combinations theroef. For example, certain IoT devices <NUM> use low range and low power wireless interfaces other than Wi-Fi, such as ZigBee, LoRaWAN, and/or BLE (Bluetooth Low Energy). <FIG> shows by enlarged view an example implementation of the hub <NUM> that can provide the above-identified wireless interface, as well as a wired LAN interface, in addition to hub <NUM> resource allocation and access priority features that will be described in greater detail in later paragraphs.

The satellite GW <NUM> can include a channel manager logic (not separately visible in <FIG>) that can be configured to establish and tear down channels (not separately visible in <FIG>) from the satellite GW <NUM> to the VSAT terminal <NUM>. Such channels can be alternatively referred to as "outroutes. " The system <NUM> can include an "outroute manager" logic (not separately visible in <FIG>) for managing such outroutes. The outroute manager can be implemented, for example, as a resource of the satellite GW <NUM>. The outroutes can be carried, for example, by assignable time-frequency slots of the forward uplink <NUM>, in series with time-frequency slots of the forward downlink <NUM> to VSAT terminal <NUM>, or time-frequency slots of other forward downlinks (not visible in <FIG>) from the satellite resource <NUM> to other VSATs (not visible in <FIG>) within satellite resource <NUM> spot beam coverage area. The time-frequency slots of the forward uplink <NUM> and forward downlink <NUM> can be per-channel assignable. This can enable time division multiple access (TDMA) multiple outroute sharing of sub-bands.

Implementations of the VSAT <NUM> can include logic, described in greater detail later, for sending requests to an inroute manager (not separately visible in <FIG>) in or associated with the satellite GW <NUM>, for additional BW for the reverse uplink <NUM>.

The VSAT terminal <NUM> can include VSAT uplink BW manager logic <NUM> for allocating to the IoT devices <NUM> and non-IoT devices <NUM> respective sub-bands or time slots of sub-bands of the reverse uplink <NUM>. The VSAT uplink BW manager logic <NUM> can also be configured to allocate to different IoT devices <NUM> and different non-IoT devices <NUM> respectively different priority of access to such uplink sub-bands or time slots. Different priority of access to uplink sub-bands or time slots can be allocated, for example, based at least in part on respective maximum delay guarantees provided to the different IoT devices <NUM> and non-IoT devices <NUM>. Implementation of such access priority can include, for example, priority queues <NUM> that can be managed, for example, by the VSAT uplink manager <NUM>. The priority queues <NUM> can include a plurality of different queues (not separately visible in <FIG>), each associated with a corresponding packet delay maximum range. Accordingly, the VSAT uplink manager <NUM> can include a logic, e.g., a mapping table (not explicitly visible in <FIG>), configured to convert or map QoS specifications that include packet delay to a particular one of the priority queues <NUM>. Such mapping is not necessarily fixed and, in an aspect, can depend at least in part on relative fill levels of the different priority queues <NUM>. In implementations of fill-level dependent queuing, the priority queues <NUM> can include or couple to a queue fill level detection logic (not visible in <FIG>).

In an example application, the IoT device type classifier <NUM> may detect and classify an IoT traffic as corresponding to an IoT device <NUM> of a first device type, and another IoT traffic as corresponding to an IoT device <NUM> of a second device type. The QoS selection logic <NUM> can in response output, respectively, a first QoS specification that can include a guaranteed first maximum delay and a second QoS specification that can include a guaranteed second maximum delay. There may be instances in which the guaranteed first maximum delay can be met by queuing the traffic in a first priority queue (not separately visible in <FIG>) among the priority queues <NUM>, while the guaranteed second maximum delay can be met using, instead, a second priority queue (not separately visible in <FIG>). Accordingly, the VSAT uplink manager <NUM> can be configured to respond by selecting, respectively, the first and the second priority queue among the priority queues <NUM>. For such applications, the VSAT uplink manager <NUM> can be further configured to dequeue from the first priority queue packets of the first IoT device type, according to a first priority dequeuing, and dequeue from the second priority queue packets of the second IoT device type, according to a second priority dequeuing, in which the first priority dequeuing may take precedence over the second priority dequeuing.

The example implementation of the hub <NUM> shown by enlarged view on <FIG> can include, as an implementation of the above-described wireless interface to IoT devices <NUM> and non-IoT devices <NUM>, a Wi-Fi interface 150a, and a non-Wi-Fi (labeled "NWF" in <FIG>) interface 150b. For various applications, the hub <NUM> can also include a wired LAN interface 150c. For purposes of description the Wi-Fi interface 150a, non-Wi-Fi interface 150b, and wired LAN interface 150c will also be referred to, collectively, as "user device interface <NUM>. " Based at least in part on interface requirements of particular application-specific IoT devices <NUM> and of non-IoT devices <NUM>, if any, implementations of the user device interface <NUM> may omit, for example, the wired LAN interface 150c.

The <FIG> example implementation of the hub <NUM> can include hub/LAN priority queues <NUM>, and a hub BW/priority manager <NUM> that can be communicatively coupled to the user device interface <NUM> and to the hub/LAN priority queues <NUM>. In an implementation, as is visible in <FIG> by connection points "A," hub BW/priority manager <NUM> can be configured to receive the output of the QoS selection logic <NUM> and further configured to selectively control, based at least in part on that QoS output, the user device interface <NUM>, or the hub/LAN priority queues <NUM>, or both. The configuration can include, for example, a mapping of QoS to hub resources, e.g., QoS latency specification to queuing selection and control parameters for the hub/LAN priority queues <NUM>. Technical features of this QoS-based, i.e., IoT device type-based, allocation of and priority of access to hub <NUM> resources can include alternative, or additional capability of the system <NUM> to meet, or more efficiently meet, or both, the different communication requirements of different IoT device types <NUM> and different non-IoT devices <NUM>, if any.

It will be understood that blocks <NUM>, <NUM>, and blocks <NUM>-<NUM> of the example implementation of the hub <NUM>, represent functions. Said blocks do not define, limit, or indicate a preference as to the implementation's architecture. As one example, the modem <NUM> may be included in an apparatus (not separately visible in <FIG>) that can also include native wireless interfaces to the IoT devices <NUM> and non-IoT devices <NUM>.

It will also be understood that the VSAT terminal <NUM> priority queues <NUM> and the hub/LAN priority queues <NUM> are logic blocks. Implementation is not limited to hardware techniques specific to queues. For example, and without limitation, implementations of the VSAT terminal <NUM> priority queues <NUM>, or the hub/LAN priority queues <NUM>, or both, can include a virtual memory space supported or hosted by an addressable random access memory RAM or RAM resource, combined with a queuing management configured RAM read-write addressing logic.

Various implementations of the VSAT terminal <NUM> can include logic (not explicitly visible in <FIG>) configured to request additional uplink bandwidth from the inroute manager. The requests can be based at least in part, for example, on detecting certain types of IoT devices <NUM>, in combination with detecting a present fill or back-up condition of the priority queues <NUM>. Examples of such implementations are described in greater detail later, e.g., in reference to <FIG> and <FIG>.

The <FIG> representation of the IoT type classifier <NUM> appears as a single block. The single block, though, is for simplicity of graphics; it can represent a collection, group, or array of IoT device type classification resources. It is not intended to limit the IoT type classifier <NUM> to include only one classifier model. For example, the IoT type classifier <NUM> can be implemented as a two-step or two part classifier model (not separately visible in <FIG>) that can include a first classifier model (not separately visible in <FIG>) and a second classifier model (not separately visible in <FIG>). The first classifier model can be implemented, for example, as a IoT device/non-IoT device binary classifier model. The second classifier model can be implemented, for example, as an R-class IoT device type classifier model, R being an arbitrary integer. The R-class IoT device type classifier model can be applied, for example, to feature data classified by the first classifier model as traffic associated with an IoT device. Example features and benefits of the IoT type classifier <NUM> being a two-step or two-part classifier can include, but are not limited to, enablement of early distinguishing of non-IoT devices, e.g., NIDs <NUM>, from IoT devices <NUM>. The first classifier model can be configured, or logic can be coupled to the first classifier model to identify information indicative of type and size of non-IoT streaming devices. Still further features can include, without limitation, provision of information that can be analyzed to determine, or assist in determining respective minimum resolutions appropriate for various streaming devices.

In example operations of system <NUM> in which the IoT type classifier <NUM> is implemented as a two-step or two part classifier, including the first classifier model and second classifier model, classifying the device between being and not being an IoT device of a particular device type can include classifying, by the first classifier model, the device between an IoT device and being a non-IoT device and, in response to the first classifier model classifying the device as being an IoT device, applying to the second classifier model an input that is based at least in part on the feature data of the IoT device. In such two-part implementation of the IoT type classifier <NUM>, the second classifier model can be further configured to classify the IoT device into one among a plurality of classes, in which the plurality of classes can include an IoT first device type class, an IoT second device type class, and an IoT device null class that includes neither the IoT first device type nor the IoT second device type. Associated with this example two-part implementation of the IoT type classifier <NUM>, the IoT device type-based QoS selection logic <NUM> can be configured such that, in response to the second classifier model classifying the IoT device as the IoT first device class, the logic <NUM> can assign a first QoS for carrying a traffic associated with the IoT device and, in response to the second classifier model classifying the IoT device as the IoT second device class, the logic <NUM> can assign a second QoS for carrying traffic associated with the IoT device.

<FIG> shows the example VSAT terminal <NUM> having just one satellite modem <NUM>. This is not a limitation on practices in accordance with this disclosure. On the contrary, implementations of the satellite modem <NUM> can include a plurality of modems providing, for example, respectively different bandwidths. In an example, the satellite modem <NUM> can include a first satellite modem (not explicitly visible in <FIG>) providing for a narrow band inroute or link, e.g., L or S band, and can include a second satellite modem (not explicitly visible in <FIG>) that can provide a broadband inroute or link. In an implementation, the VSAT uplink BW manager <NUM> can be configured to provide, based for example on the QoS output from the QoS selection logic <NUM>, selection between the first and second satellite modem. In an implementation, the BW manager <NUM> can be configured to select between the first and second modem to provide the reverse uplink <NUM> as a hybrid link with resources that are allocated as appropriate for an IoT device type. For example, in accordance with one configuration for the BW manager <NUM>, for short and sporadic messages that are critical the narrowband L or S-band links can be selected, e.g., together with the first satellite modem, as the narrowband L or S-band links can provide very reliable delivery. The BW manager <NUM> can be likewise configured to send high volume background traffic, in contrast, through the broadband/wideband links, e.g., via the second satellite modem.

In another implementation a system can feature both geostationary earth orbiting (GEO) satellite service and low-earth orbiting (LEO) satellite service, with IoT device type based selection and assignment of selecting between can select for IoT device traffic having a low latency requirements and between a LEO and GEO satellite link.

The system <NUM>, and various other systems disclosed herein can provide, among other features, real-time, IoT device-type adaptive assignment of QoS to IoT device traffic, through features that can include monitoring of a VSAT local network traffic, extracting fingerprint features from the monitoring, applying the extracted fingerprint features to a particularly trained ML classifier detection of a new flow, generating or outputting at <NUM> for classifying the feature data, based at least in part on a machine learning classifier, between indicating and not indicating network traffic flow associated with a particular IoT device. Generating, e.g., at <NUM>, based at least in part on a result of classifying the feature data, a classification result and based at least in part on the classification result indicating network traffic flow associated with the particular IoT device type, assigning a corresponding QoS specification for bearing the network traffic flow associated with the particular IoT device type.

<FIG> is a block schematic of one example system <NUM> for IoT device detection, classification, and corresponding real-time allocation and prioritization to VSAT bandwidth, providing a hybrid GEO-LEO multi-layer link between the VSAT terminal <NUM> and IoT server <NUM>, instead of the single layer satellite link that is visible in system <NUM>. The hybrid GEO-LEO multi-layer link can be implemented by supplementing the satellite BW <NUM> with a LEO satellite GW <NUM>, which can be connected to the Internet <NUM> via, for example, LEO IP GW <NUM>, and can be configured to connect by forward uplink <NUM> and reverse downlink <NUM>, to a LEO satellite, labeled 212j, that serves as a LEO ground station edge node, for the duration that it is within the horizon of the LEO satellite GW <NUM>. The LEO ground station edge node 212j can be a successively changing LEO satellite among an orbiting constellation of LEO satellites.

The VSAT terminal <NUM> can include, in addition to the satellite modem <NUM> described above, a LEO satellite modem <NUM> and a modem selector <NUM>. The modem selector <NUM> can be configured to select, for the hub <NUM>, among the satellite modem <NUM> and the LEO satellite modem <NUM>. The modem selector <NUM> can perform the selection based at least in part on QoS (if any) selected by the above-described QoS selection logic <NUM>.

The LEO satellite modem <NUM> can connect by forward downlink <NUM> and reverse uplink <NUM> to LEO satellite 212j+B, the VSAT terminal LEO edge node, which can be another among the orbiting constellation of LEO satellites. Each LEO satellite can be configured to construct, and when necessary tear down, a pair of intersatellite links, such as the examples labeled ISLj,. , ISLj+B-<NUM>, ISLj+B. The value B is an integer that can be determined, for example, by the spacing between the LEO satellites and the geographical distance between the LEO satellite GW <NUM>. An outroute from the LEO satellite GW <NUM> to the VSAT terminal <NUM> can therefore be provided by the forward uplink <NUM> to the LEO GW edge node 212j, followed by integer B hops through intersatellite links ISLj,. , ISLj+B-<NUM>, ISLj+B. to the VSAT terminal LEO edge node 212j+B, and then the forward downlink <NUM>. In like manner an inroute can be provided from the VSAT terminal <NUM> to the LEO satellite GW <NUM>, via reverse uplink <NUM> to the VSAT LEO edge node 212j+B, followed by a reverse direction traversal of the integer B ISL hops to the LEO GW edge node 212j, and then the reverse downlink <NUM>.

Notwithstanding there being integer B hops in the above described forward and reverse LEO paths between the VSAT terminal <NUM> and the LEO satellite GW <NUM>, a time delay incurred in carrying IoT device <NUM> packets over such forward/reverse LEO paths can be significantly less than the time delay incurred in transmission using the GEO satellite <NUM>. Implementations of the system <NUM> can therefore be configured such that in response to a QoS from the QoS selection logic <NUM> specifying a guaranteed maximum delay less than a particular threshold, the modem selector <NUM> can connect the hub <NUM> to the LEO satellite modem <NUM>.

In one example application of the system <NUM>, the classifier <NUM> may detect and classify an IoT traffic as corresponding to an IoT device <NUM> of a first device type, and another IoT traffic as corresponding to an IoT device <NUM> of a second device type. In instances, the QoS selection logic <NUM> may output, respectively a first QoS specification includes a guaranteed first maximum delay and a second QoS specification includes a guaranteed second maximum delay. The may be instances in which the guaranteed first maximum delay is within a threshold that can be met by the GEO satellite <NUM>, while the guaranteed second maximum delay is less than that threshold, i.e., cannot be met by the GEO satellite <NUM>. The system <NUM> modem selector <NUM>, accordingly, can connect the hub <NUM> to the LEO satellite modem <NUM> for carrying the IoT first device type traffic, and to the LEO satellite modem <NUM> for carrying the IoT second device type traffic.

The system <NUM> can therefore provide real-time selection of a shorter system delay in response to detecting and classifying, by their respective traffic fingerprints, medical or health monitor IoT devices <NUM>. System <NUM> can provide further benefit, by providing high reliability, low latency LEO delivery to the IoT server <NUM>, of alarms or reports from medical or health monitor IoT devices <NUM>. Implementations of the system <NUM>, as well as the system <NUM>, can be further configured to generally apply a more robust modulation and coding (MODCOD) for traffic from medical or health monitor IoT devices <NUM>, as such traffic can be low volume, and can benefit from for immediate delivery, for example, via SCMA channel, without need for requesting inroute bandwidth.

There can be some types of IoT devices from which traffic can be considered critical but, at least in some applications, not as critical as life-threatening traffic from health monitor devices. An example of such IoT devices can be any among a variety of IoT security devices. Criticality of such traffic, e.g., in terms of acceptable delay and reliability, may be classified, for example, proximal to the criticality for health monitor related traffic.

Traffic characteristics from cameras can be high volume in nature and do not generally require low latency treatment. This traffic can be sent as a background priority as a best effort traffic.

Referring to the priority queues <NUM>, IoT devices <NUM> of device types whose traffic does not require immediate delivery can be queued for some time at the satellite modem and then sent, using the stream inroute bandwidth, when sufficiently large number of packets are queued. Features and benefits can include, without limitation, efficient usage of satellite resource usage. Further, this can reduce or eliminate necessity of using Aloha channel or SCMA channel which are costlier schemes of sending inbound traffic that, absent the described features of system <NUM>, can be required when sporadic IoT packets require immediate sending.

<FIG> is a flow diagram of example operations in processes <NUM> in training and applying a machine learning IoT device type classifier, for IoT device detection and type classification, and IoT type-based adaptive allocation and prioritization of access to VSAT bandwidth. Description of example aspects and features of the flow <NUM> will make reference to the <FIG> system <NUM>. Such reference is for convenience of tracking described example operations relative to an already described example system. It is not intended to limit practices according to the flow <NUM> to being on the system <NUM>. An example instance of the flow <NUM> can proceed from an arbitrary start state <NUM> to a training phase or mode <NUM>, which can include applying operations at <NUM> for training an IoT device type classifier <NUM> to implement, for example, the system <NUM> IoT device type classifier <NUM>. Specific operations and combinations of operations applied at <NUM> can be defined in part by the type of IoT device type classifier <NUM>. For example, if the classifier <NUM> is a neural network classifier, operations and combinations thereof applied at <NUM> can be configured according to one or more machine learning processes for training neural network classifiers.

One example training process can be "supervised. " Example implementations of supervised training processes that may be applied at <NUM> are described in greater detail later in this disclosure. These include, but are not limited to, process(es) described in reference to <FIG>.

In an implementation, training processes applied at <NUM> can include, alone or in combination with supervised training, an "unsupervised" training. One example type of unsupervised training process that can be applied is "k-means clustering. " k-means clustering can be applied to network and application layer attributes of traffic across many types, brands, and functionalities IoT devices. In overview, instances of k-means clustering can include starting with a number, N, of bins, and applying an iterative clustering of the IoT device types into the N bins. The value N can be adjusted. Various known techniques of k-means clustering can be used. Such techniques are described by a large number of readily available publications and, therefore, further detailed description is omitted.

An aspect of configuring the training at <NUM> as a k-means clustering, is that the clustering indicates that IoT device types within each cluster have particular similarities. The clustering, however, does not necessarily provide explicit identification of the specific type or types of IoT devices that are within each of the N clusters. Irrespective of this aspect, though, k-means clustering can be used at <NUM>, and can provide at <NUM> a useful classifier <NUM> for practices of systems and methods according to this disclosure. Benefits of such implementation can include, but are not limited to, the following: once a device is classified using the supervised learning approach, a similar type of device can be easily identified without going through expensive training phase. Also, unsupervised learning can be preferable in some applications, such as when no labeled data can be available from IoT devices, i.e., no labels can be derived from a training process.

Implementations of unsupervised training at <NUM> are not limited to k-means clustering. Alterative implementations can include, but are not limited to, mean-shift clustering, agglomerative hierarchical clustering, and Expectation-Maximization clustering using Gaussian mixture.

It will be understood that the training at <NUM> is not necessarily applied as a one-time operation. On the contrary, the training <NUM> can be repeated, for example, and without limitation, in a periodic manner, or in accordance with a schedule, or in accordance with a selected or specified frequency or average frequency of training repeats, or any combination or sub-combination thereof. Particularities as to schedule, frequency or average frequency, or other parameters other.

Resources for performing training operations at <NUM> can include, for example in the <FIG> VSAT <NUM>, general purpose programmable processor resources (not explicitly visible in <FIG>), coupled to a memory resource (not explicitly visible in <FIG>) that can store machine-executable instructions that, when executed by the processing resource, cause the processing resource to perform such training process(es). Example implementations are described in greater detail in reference to <FIG>.

Referring to <FIG>, upon completion of the training operations at <NUM>, yielding the trained IoT device type classifier <NUM>, the flow <NUM> can proceed to <NUM> and enter an operational phase or mode. Operational flow at <NUM> can be in the context of normal operations at <NUM> of one or more of the <FIG> IoT devices <NUM>, as well as one or more of the NIDs <NUM>. Operations at <NUM> can include operations at <NUM> of monitoring a traffic, for example, on a VSAT local link that carries traffic, including IoT traffic, for transmission on an inroute carried in part by the VSAT-to-satellite uplink <NUM>, toward the satellite GW <NUM>. Referring to <FIG>, examples of operations at <NUM> can be performed by the flow monitor <NUM> connecting, e.g., via a network tap, to the hub <NUM>.

Detection of a new traffic flow, e.g., by monitor operations at <NUM> is shown by the "YES" outbranch from decision block <NUM> and, in response, the flow <NUM> can proceed to <NUM> to output or retrieve extracted flow features, and then to <NUM> where operations can apply the extracted flow features to the trained classifier model <NUM> resulting from the training operations at <NUM>. In response to operations at <NUM> not indicating the new flow detected at <NUM> corresponds to a known IoT type, i.e., not being among the IoT device types for which classifier model <NUM> was trained at <NUM>, the flow <NUM> can return to <NUM> via the "No" outbranch of decision block <NUM>. It will be understood that "return to <NUM>" relates to the flow path of <NUM> for the particular new flow that was detected <NUM> but then determined at <NUM> as not matching a known IoT device type. Monitoring operations at <NUM> are not necessarily halted or terminated in response to each detection at <NUM> of a new flow.

In response to operations at <NUM> indicating the new flow detected at <NUM> as matching one of the IoT device types for which classifier model <NUM> was trained at <NUM>, the flow <NUM> can proceed from the "Yes" outbranch of decision block <NUM> to <NUM>. Operations applied at <NUM> can include, based for example on an identifier of the matching IoT device type, retrieval of QoS specifications for that particular IoT device type. Referring to <FIG> and <FIG>, operations at <NUM> can be performed, for example, by the QoS selection logic <NUM>. The process <NUM> can then proceed, for the particular detection at <NUM> that, at <NUM>-<NUM>, matched an IoT device type for which the classifier model is trained, to <NUM>, or to both <NUM> and <NUM>. Operations at <NUM> can be configured to allocate uplink resources of the VSAT <NUM> in a manner that can carry traffic associated with the subject IoT device, with a QoS sufficient to meet the IoT device type requirements. Such operations can include, for example, assigning time slots on the uplink <NUM>. Operations at <NUM> can also include assigning uplink traffic from the subject IoT device to a particular one of the priority queues <NUM>, or assigning a higher priority de-queuing to said traffic, or both.

In addition, in an instance of the flow <NUM> performed on a system according to the <FIG> system <NUM>, operations applied at <NUM> can include selecting, e.g., via the satellite modem selector <NUM>, between the GEO modem <NUM> and the LEO modem <NUM>.

Operations at <NUM>, if included, can be configured to allocate bandwidth of the hub <NUM>, or assign access priority to the hub resources, or both, in a manner that efficiently applies sufficient hub resources such that, in combination with operation of the VSAT local uplink BW manager <NUM> in allocating uplink resources, can meet the QoS selected by the QoS selection logic <NUM>. Operations at <NUM>, if included, can be controlled at least in part by the BW/priority manager <NUM>. Such operations can include, for example, assigning the IoT device traffic to a higher priority queue, e.g., among the hub/LAN priority queues <NUM>, and de-queuing from the queues <NUM>, or both.

As will be described in greater detail later in this disclosure, further implementations can include, for example, in the VSAT <NUM> of system <NUM> or comparable VSAT terminal of system <NUM>, a configuration of block <NUM> can include providing for the VSAT <NUM> to send, for example, to a network inroute manager a request for additional uplink bandwidth. Examples of such implementations are described in greater detail later, including in reference to <FIG> and <FIG>.

<FIG> is a flow diagram of example operations in a process <NUM> for supervised machine learning training of a fingerprint based IoT device type classifier, which can be an implementation of <FIG> flow <NUM> blocks <NUM> and <NUM>. As described above, resources for performing process <NUM> or operations or portions thereof, and which can be included in system <NUM>, system <NUM>, and other systems disclosed herein, are described later, for example, in reference to <FIG>.

Referring to <FIG>, an instance of the flow <NUM> can include proceeding from an arbitrary start at <NUM> to <NUM> where traffic can be generated by and in association with an assortment of different types of IoT devices different types of non-IoT devices. Concurrent with operations at <NUM>, the flow can include, at <NUM>, monitoring the corresponding traffic to collect raw traffic data. The flow <NUM> can proceed from <NUM> to <NUM>, where operations can be applied for extracting features from the raw traffic data. Examples of such features that can be extracted from the network traffic of IoT devices can include, but are not limited to:.

From <NUM> the flow <NUM> can proceed to <NUM> and <NUM> to generate, respectively, a training data and a test data. Operations at <NUM> and <NUM> can include label each flow and the extract statistical properties. Examples can include, but are not limited to, can include.

Other properties (such as port number, tcp/udp/icmp, etc.) from the raw data can also be used to create training data.

The flow <NUM> can proceed from <NUM> and <NUM> to a loop formed by <NUM> and <NUM>, which can iteratively construct and train a classifier model, and can continue looping until operation at <NUM> detects a loop exit condition, for example, the classifier model having accuracy meeting a minimum allowable level. Implementation and configuration of the operations at <NUM> and <NUM> can depend on the type of classifier model being constructed and trained. For example, assuming the intended classifier model is a deep neural network, each iteration can include, at <NUM>, adjusting the model weights and feeding the training data to the adjusted classifier model followed by determining, for example based on the test data generated at <NUM>, if the adjusted model shows sufficient accuracy. Upon meeting the condition at <NUM>, the flow <NUM> can result, as shown by block <NUM>, in a trained neural network classifier.

<FIG> is a block schematic of one example system <NUM> for IoT device detection and type classification, and type-based allocation and prioritization of access to VSAT bandwidth, in combination with IoT type-based system allocation of bandwidth to VSATs. The example implementation of system <NUM> visible in <FIG> is shown as a modification of the <FIG> system <NUM>. This is to assist in focusing description on particular concepts, and example features and operations illustrative of same. It is not intended to limit implementations of system <NUM> to being a modification of system <NUM>. Like numbered blocks have functions, aspects, and features as described above in reference to <FIG> and therefore, for the sake of brevity, description of same is not repeated here, except where incidental to a described operation or feature.

One example implementation of system <NUM> can be realized by the following modifications to system <NUM>: adding, for example by including in satellite GW <NUM>, an inroute manager <NUM>, this modification being visible in <FIG> as satellite GW <NUM>; and adding, for example by including in VSAT <NUM>, a VSAT-to-inroute manager BW request logic <NUM>, this modification appearing in <FIG> as VSAT <NUM>. Implementation of the inroute manager <NUM> can be for example,, as described in <CIT> and issued April <NUM>, <NUM> (hereinafter "the '<NUM> patent"). Implementation of the VSAT-to-inroute manager BW request logic <NUM> can include an adaptation of VSAT bandwidth request features described in the '<NUM> patent. For example, the VSAT-to-inroute manager BW request logic <NUM> can be configured to monitor the priority queues <NUM> and, for example, based in part on backlog of the queues <NUM>, to send a request to the inroute manager <NUM> for additional bandwidth. For example, the VSAT-to-inroute manager BW request logic <NUM> may send such a request in response to the IoT type classifier <NUM> classifying a device as an IoT device type with QoS requirements that cannot be met in view of current queuing backlog and current allocated uplink <NUM> bandwidth BW.

<FIG> is a flow diagram of example operations in processes <NUM> in training and applying a machine learning IoT device type classifier, for IoT device type-specific adaptive allocation of VSAT bandwidth, in combination with VSAT IoT type-based requesting of bandwidth. The example implementation of <NUM> visible in <FIG> is shown as a modification of the <FIG> flow <NUM>. This is to assist in focusing description on particular concepts, features and operations illustrative of same. It is not intended to limit implementation of <NUM> to being a modification of flow <NUM>. Like numbered blocks have functions, aspects, and features as described above in reference to <FIG> and therefore, for the sake of brevity, description of same is not repeated here, except where incidental to a described operation or feature. In an instance of the flow <NUM>, operations can proceed from the above-described start <NUM>, to training at <NUM> and, from the training at <NUM>, to <NUM>. Operations applied at <NUM> can include operations applied at <NUM> through <NUM>, as described in reference to <FIG>. Operations at <NUM> can also include, as represented by <FIG> block <NUM>, the <FIG> operations described in reference to blocks <NUM> and <NUM>.

Aspects of the flow <NUM> not described in reference to the flow <NUM> can include, e.g., after retrieval of QoS specifications at <NUM> and in association with or with some portions of operations at <NUM>, proceeding to <NUM>. At <NUM> operations can be applied to determine if the VSAT requires additional uplink bandwidth to meet the IoT device type-specific QoS identified at <NUM>. Operations applied at <NUM> can include detecting backlog levels in the priority queues <NUM>. In an implementation, operations at <NUM> can be parallel to, or can be incorporated within the operations at <NUM>. If the determination at <NUM> is that additional VSAT BW is necessary, the flow <NUM> can proceed, as shown by the YES outbranch of decision block <NUM>, to <NUM>, where the VSAT can apply operations to send a request for bandwidth to the inroute manager <NUM>.

Referring to <FIG>, <FIG>, and <FIG>, system <NUM>, the flow <NUM>, and the <FIG> system <NUM> are described with reference to one example VSAT terminal, e.g., VSAT terminal <NUM> and the VSAT terminal <NUM>. Another implementation according to <FIG> can include multiple VSAT terminals, each configured generally as VSAT terminals <NUM>. In one example of such implementation, all the VSATs can include its own classifier model <NUM>. Training of each can be as described above in reference to <FIG>. However, since the different VSATs may be associated with respectively different customer premises, there may be different sets of IoT device types used in their respective training. Each of the different VSATs may therefore provide an acceptable accuracy, for the IoT device types it was trained with. This can impose various costs. For example, for each instance of a VSAT <NUM> classifier model <NUM> encountering an unrecognized IoT device type, the VSAT's QoS selection logic <NUM> may mis-allocate bandwidth, or an improperly assign priority for the IoT device's traffic. In systems such as satellite communications, such misallocation and improper assignment can be costly. In addition, in at least some instances of the VSAT <NUM> classifier model <NUM> encountering an unrecognized IoT device type, a quality of service rendered or provided by the IoT device can be degraded from the level that may be provided for recognized IoT device types.

One example alternative implementation system according to this disclosure can provide a substantial reduction in the above-described occurrences of system <NUM> encountering unrecognized IoT device types and, in turn, reduce corresponding system costs. In one example implementation, a plurality of VSATs can be configured as the system <NUM>, and each can be trained with a respective assortment of IoT device types, as described. A server can also be provided, with logic that can receive the different VSATs' trained models, as partial models, and can combine the partial models into what may be termed a superset classifier. An implementation of such server logic can also provide distribution or downloading, to many VSATs, of the superset classifier model. Features and benefits of such implementations can include, without limitation, classifier models such as the system <NUM> wherein prior to a new type of IoT device being introduced onto a VSAT serviced premises <NUM>, the classifier model <NUM> is already present.

Another system in accordance with this disclosure, which can be implemented based in part on the <FIG> system <NUM>, the <FIG> system <NUM>, or the <FIG> system <NUM>, can include a central resource, e.g., server, logic and a corresponding VSAT client logic that can provide collective training of classifier model. Features can include pooling of data and processing resources of thousands, hundreds of thousands, or millions of VSATs. In an example, a server can be included, which can include resources for instantiating what will be labeled, for purposes of description, as a "baseline model" or "BM. " It will be understood that as used in this description the phrase "baseline model" and its abbreviated form "BM" are only labels; they have no intrinsic meaning regarding classifier model type, model architecture, model principle of operation, model arithmetic operations, model logic operations, or the technologies for implementation(s) of the model.

The BM can be implemented, for example, as a neural network classifier model. The instantiation can include a supervised training. The supervised training can include, generally, aspects and features comparable to those described above in reference to <FIG>, block <NUM>. In one more aspects, the centralized resource, e.g., server configuration can provide distribution or download of the BM to a plurality of VSATs. One example VSAT implementation can generally include the VSAT terminal <NUM>, configured with an installed client that, for example, under control of the server, can perform or cause other resources of the VSAT to perform a retraining of the BM, and upload the retaining results to the server. The central resource, e.g., the server, can further include logic for merging or combining the uploaded retraining results and logic that, based in part on the combining, can generate and distribute an updated BM.

<FIG> a block schematic of an implementation of a system <NUM> for fingerprint based detection and classification IoT device type, and IoT type-based adaptive allocation and access priority to VSAT bandwidth, with server distribution of BM, and federated multiple VSAT retraining, with centralized update and redistribution of BM.

For brevity, system <NUM> will be described as based in part on the <FIG> system <NUM>, with common blocks maintaining the <FIG> block numbering. It will be understood that such description is for convenience and is not to be understood as a preference as to implementations of federated learning according to this disclosure.

The system <NUM> can include a server <NUM> that can include a BM logic <NUM> that can store a BM and distribute or push copies of the BM to each of a first VSAT <NUM>-<NUM>, second VSAT <NUM>-<NUM>,. , Sth VSAT <NUM>-S (collectively "VSAT terminals <NUM>"). The population S can be arbitrary. Example populations can be in the tens, hundreds, thousands, hundreds of thousands or more. As visible in <FIG>, VSAT terminal <NUM>-<NUM> is arbitrarily selected for enlarged view of functional blocks that can be representative of functionalities common to all VSAT <NUM>. Alternatively, the VSATs <NUM> can be configured to send a request to the server <NUM>, for example in response to an event such as start-up or reset.

There can be a forward uplink <NUM> and reverse downlink <NUM> between the satellite GW <NUM> and the satellite resource <NUM>. The FL server <NUM> can push copies of the BM to the VSATs <NUM>, for example, via the Internet <NUM>, IP GW <NUM>, and satellite GW <NUM>, over forward uplink <NUM> to the satellite resource <NUM>, and then to the VSAT terminals <NUM> via forward downlinks <NUM>-<NUM>, <NUM>-<NUM>,. <NUM>-S (collectively "forward downlinks <NUM>"). Each of the VSATs <NUM> can, in turn, store the received BM as a VSAT centralized classifier local copy (CLC) <NUM>. The VSAT CLC <NUM> can be stored, for example, in a VSAT centralized classifier copy storage (not separately visible in <FIG>). The VSAT centralized classifier copy storage can be implemented by a memory resource (not separately visible in <FIG>).

In an aspect, various operations of the VSAT terminals <NUM> can be controlled, at least in part, by a client application such as the VSAT terminal <NUM>-<NUM> federated learning (FL) client <NUM>. As described in greater detail later in this disclosure, certain of such operations can relate to scheduling and sequencing of terminal <NUM> processes in retraining of the VSAT CLC <NUM>.

In one implementation, instantiation of the BM can include reception at the FL server <NUM>, for example, from a source external to <FIG>. In another implementation, the FL server <NUM> can include a BM instantiation/training logic (not separately visible in <FIG>) that can apply, for example, to a BM template a training process to form the initial configuration of the BM <NUM>.

Each of the VSATs <NUM> can include, either as a single device or a combination of devices, a modem <NUM>, and a hub <NUM> that can connect to the modem <NUM>. The connection can be direct or, for example, through a queuing block <NUM>, or both. Each VSAT <NUM> can include a flow monitor <NUM> (labeled "FM" <NUM> in <FIG>) that can feed flow data to the VSAT CLC <NUM>. Each of the VSATs <NUM> can include a VSAT bandwidth manager (labeled "VPPM" on <FIG>) <NUM>. Functionality of the VSAT bandwidth manager <NUM> can include the above-described QoS selector logic <NUM> of the <FIG> system <NUM>. The modem <NUM> can correspond, for example, to the <FIG> system <NUM> modem <NUM>. Functionality of the flow monitor <NUM> can include the above-described functionality of the system <NUM> flow monitor <NUM>. Configured as such, each of the VSATs <NUM>, after receiving and storing the original pushed BM as the current VSAT CLC <NUM> can proceed to a process such as block <NUM> of the <FIG> process <NUM>.

At some time, or in response to some event or condition, a system <NUM> resource (not explicitly visible in <FIG>) can send notification to all of, or to some of the S VSATs <NUM>, to apply a retraining to their respective VSAT CLC <NUM>. The FL client <NUM> can be configured such that, in response to such notification, it immediately switches the VSAT <NUM> to a federated training mode. In the federated training mode, the VSAT <NUM> can first generate training data and test data and then, at a later time, can apply retraining operations on its VSAT CLC <NUM> to form an individually updated CLC (not separately numbered). The VSATs <NUM> can be configured or controlled by the FL client <NUM> to apply the training in two parts. The first part can include generating and storing training data. The second part can be performing the retraining, for example, when the VSAT <NUM> has time and resources.

Functionality of the VSAT individual retraining logic <NUM> can include uploading, to the FL server <NUM>, the individually updated CLC resulting from the re-training. The FL server <NUM> can include a centralized classifier updating logic <NUM> (labeled "BMUL" <NUM> in <FIG>) that can be configured to perform an updating of the most recently pushed centralized classifier model, the first of which was the BM, based on a combining of multiple uploaded individually updated CLCs. In implementations described in greater detail later in this disclosure, features of the centralized classifier updating logic <NUM> can include conditioning its updating process on receiving a threshold population of uploaded updated CLCs. Another feature of the centralized classifier updating logic <NUM> can include performing a combining of the uploaded individually updated CLCs. Other combining modes are described in greater detail later in this disclosure. The result can be an updated centralized classifier model <NUM>. The FL server <NUM> can include logic (not separately labeled in <FIG>) for downloading or pushing the updated centralized classifier model to the VSATs <NUM>, as a new centralized classifier model. In an implementation, described in greater detail later in this disclosure, the server <NUM> can include a qualification logic that can be configured to push the updated centralized classifier model, as the new centralized classifier model, only if an accuracy improvement condition is met.

In various applications, considerations in the selection of the type of classifier model for implementing the baseline model can include combinability of individually retrained copies, e.g., and performance effects of such combining. For example, deep neural networks, identified above as one implementation of the BM <NUM> can be combined, e.g., as described above in reference to centralized classifier updating logic <NUM>. There can be applications, though, wherein particular requirements or target performance, e.g., with respective to particular IoT device types, may be easier met or easier supported through classifier model types that may not be as readily combined. The <FIG> implementation of system <NUM> can provide for such applications, as it can include in one or more of the VSAT <NUM>, in addition to the described BM and updates thereof stored as CLC <NUM>, one or more individual classifier models, such as the representative BMI <NUM>. As visible in <FIG>, the BMI <NUM> can be configured to selectively receive feature data from the feature monitor <NUM> and provide the classification result to the VSAT bandwidth manager <NUM>. Therefore, VSAT <NUM> operations and performance with the BMI <NUM> enabled, with respect to detection and classification IoT device type, and corresponding adaptive allocation of uplink resources, can be as described above, for example, in reference to <FIG> and <FIG>.

<FIG> is a flow diagram of example operations in processes <NUM> of FL server distribution of the original BM, VSAT application of the BM for IoT device detection, type classification, type-based QoS selection, and carrying of IoT device traffic, and federated retraining of the BM. For brevity, description of example interactions and performances of operations will be in general reference to the <FIG> system <NUM>.

One instance of the flow <NUM> can proceed from an arbitrary start <NUM> to <NUM>, where operations can be applied for instantiating a BM. An example instance of flow <NUM> can proceed from <NUM> to <NUM> and where operations can push the instantiated BM from the federated learning server to VSATs enabled with FLC. Referring to <FIG> and <FIG>, example operations at <NUM> can include the <FIG> FL server <NUM> pushing the instantiated BM from the BM logic <NUM> to the VSATs <NUM> running the FL client <NUM>. Each of the FL client <NUM> enabled VSAT <NUM> can then download the instantiated BM from the FL server <NUM> and store the BM as the VSAT CLC <NUM>.

From <NUM> the flow <NUM> can proceed to <NUM>, where, at FL client <NUM> enabled VSATs <NUM> that have received and stored the original BM as a the VSAT CLC <NUM>, operations can be applied that can provide real-time IoT device detection, IoT type-based classification and assignment of VSAT BW, or priority of access to VSAT BW, or both. Operations at <NUM> can be, for example, as described in reference to <FIG>, block <NUM>.

The flow <NUM> can maintain operation at <NUM> until for example, receipt of a command or instruction or detection of another event defined as a trigger for a federated retraining of the VSAT <NUM> CLCs <NUM>. The flow <NUM> can then proceed from <NUM> to <NUM> and apply operations that can include, at one or more of the VSATs <NUM> enabled with FL client <NUM>, individual retraining of the centralized classifier copy received and stored at <NUM>, to form an individually updated centralized classifier, and uploading the individually updated centralized classifier to the FL server <NUM>. Some operations at <NUM> can be applied by the FL server <NUM>, such as combining the uploaded locally updated centralized classifiers into an updated centralized classifier model and pushing the updated centralized classifier model to the VSATs <NUM> enabled with the FL client <NUM>, as a new centralized classifier copy.

<FIG> is a block schematic of one implementation of a system <NUM> for fingerprint based detection and classification IoT device type, and IoT type-based adaptive allocation and access priority to VSAT bandwidth, with server distribution of BM, federated multiple VSAT retraining of BMs and upload of same, with associated server updating and conditional redistribution of BM.

The system <NUM> can be implemented, for example, as an adaptation of the <FIG> system <NUM>. As visible in <FIG>, an example of such adaptation can include a modification of the FL server <NUM>, referenced as <NUM> on the figure, in combination with an added network management system <NUM>, in further combination with a particular implementation of the <FIG> VSAT individual retraining logic <NUM>. As visible in <FIG>, one example of the particular implementation of the VSAT individual retraining logic <NUM> can include a retraining logic (hereinafter "RTR logic") <NUM> and a training data storage <NUM>.

The network management system <NUM> can be configured to instruct the VSATs <NUM> to initiate individual retraining of the VSAT <NUM> CLCs <NUM>, for example, by transmitting to the VSATs <NUM> an initiate retraining instruction (not separately visible in <FIG>). Example functions of the RTR logic <NUM> can include, in response to the receiving the initiate retraining instruction, causing or controlling the flow monitor <NUM> to load the FL Data storage <NUM> with training data. Other retraining functions of the RTR logic <NUM> can include controlling the training data storage <NUM> and VSAT CLC <NUM> to perform retraining iterations, until detecting an exit condition. In a neural network implementation of the server BM <NUM> and hence VSAT CLC <NUM>, each of the retraining iterations can include, for example, an incremental adjusting of the CLC <NUM> neural network weights, then feeding the training data from <NUM> to the adjusted CLC <NUM>, inspecting the classification result and, absent the result meeting the exit condition, again adjusting the neural network weights and repeating the process. An example exit condition can be the RTR logic <NUM> detecting a less-than-threshold per-iteration increase of classification accuracy.

In an aspect, the RTR logic <NUM> can be configured to control scheduling of the iterative individual retraining, for example, by collecting and storing training data <NUM> during regular operations of the VSAT <NUM>, without commencing the retraining iterations and, at a later time, performing the retraining iterations.

The particular modification of the FL server <NUM> referenced as <NUM> on <FIG> can include an upload individual retrained BM (hereinafter alternatively referred to "URBM") logic <NUM>, a combine uploaded individually retrained BM (hereinafter alternatively referred to "CUBM") logic <NUM>, and a qualification of combined retrained BM (hereinafter alternatively referred to "QCBM") logic <NUM>.

The RTR logic <NUM> can be configured such that, in response to detecting termination of the above-described retraining, the logic <NUM> can upload the individually retrained CLC <NUM> to the FL server's URBM logic <NUM>. The URBM logic <NUM> can be configured to increment a counter, or logical equivalent, upon each receipt of an uploaded individually retrained BMs and configured to cause or initiate, when the count meets what will be termed a "individual retrained BM count threshold," the CUBM logic <NUM> to combine the uploaded individually retrained CLCs into a combined model. In one implementation, the FL server <NUM> can automatically update its current centralized classifier model <NUM> based on a result of the CUBM logic <NUM> combining operations. In an implementation as visible in <FIG>, wherein the FL server <NUM> includes the qualification of combined retrained BM logic <NUM>, the FL server <NUM> can condition pushing the result of the CUBM logic <NUM> combining, on that result having an accuracy that is more than an update threshold. In other words, if the updated centralized classifier model meets improvement threshold, push it to the VSATs <NUM>, and if not, do not push it.

<FIG> is a flow diagram of example operations of a flow <NUM> in one process of federated multiple VSAT retraining of BMs, upload of VSAT retrained BMs to server, centralized combining of uploads and conditional pushing of updated BM based on same. The <FIG> flow <NUM> can be a detailed implementation of the <FIG> block <NUM>, as shown by the connection points "B" and "C" that are visible both on <FIG> and <FIG>.

It will be appreciated that many, e.g., hundreds of thousands, VSATs <NUM> can be running the federated learning client <NUM> and each can perform the <FIG> flow <NUM> retraining on its VSAT CLC <NUM>. Each of the many VSATs <NUM> configured with the FL client <NUM> can therefore, in addition to using the most recent new centralized classifier model pushed by the FL server <NUM>, can participate in retraining of its copy of same, e.g., CLC <NUM>, and in providing a new incremental CLC back to the FL server <NUM>. This will be understood from the description above, and further understood from the following description of the flow <NUM>, including example operations and flow features.

In an instance of the flow <NUM> can start at connection point "B" on <FIG>, representing a population of VSATs running the FL client <NUM> and which have received the pushed new centralized classifier model from the FL server <NUM> (and <NUM>) BM logic <NUM>. From connection point B, the flow <NUM> can proceed to <NUM>, where the network management system <NUM> can select, for example by random selection techniques, integer M of the VSATs <NUM> running the FL client <NUM>. Contemplated values of M can be large, e.g., in the hundreds of thousands or millions, or can be smaller. The flow <NUM> can proceed from <NUM> to <NUM> where operations, for example by the network management system <NUM>, can send an initiate training command (hereinafter ""ITR command") to the M VSATs <NUM>. The flow <NUM> can proceed from <NUM> to <NUM>, and from <NUM> to <NUM>, as will be described in greater detail, the flow <NUM> can be individual to each of the M VSATs <NUM>.

From the perspective of each of the M VSATs <NUM> at <NUM>, specific response to receiving the ITR command can depend, at least in part, on the VSAT's present operational load. A general response, which can be performed while continuing its regular operations, can be an immediate or near-immediate conversion of received traffic flow data, e.g., from the flow monitor <NUM>, to training data, and loading of the training data into the training data storage <NUM>. This conversion of traffic flow data into training data, and storage of same in the storage <NUM>, can continue for a duration (DRN). The value of DRN can be set, for example, by the ITR command. Operations applied at <NUM> can also include, in an alignment with storing of the training data in storage <NUM>, a loading of the VSAT <NUM> current BM classification of the IoT device corresponding to the traffic flow for which the training data was generated.

At <NUM> each VSAT <NUM> can perform a scheduling operation, to set a time for performing its individual retraining process. <FIG> shows operations at <NUM> performed after DRN. In such a case, the flow <NUM> can proceed from <NUM> to <NUM> and wait with respect to performing the retraining. Conceivably, scheduling at <NUM> can be performed during DRN. In such a case, operations at <NUM> can be concurrent with the wait at <NUM>.

Features and benefits provided by flow portions <NUM> to <NUM> can include, but are not limited to, system-wide enablement for a large number, M, of VSATs <NUM>, to participate in and contribute to a federated training of the originally pushed BM, as well as federated training of each subsequently pushed new centralized classifier model. This enablement, and other features, can be provided in part by each VSAT <NUM> starting, e.g., in response to the ITR command, its converting of raw input data (traffic flows) into training data and storing the training data locally in its storage <NUM>, irrespective of the VSAT <NUM> not being in a position to actually run the model training at the time. This also enables each VSAT <NUM> to store training data and classification results from its current VSAT CLC <NUM>, for retraining the current CLC <NUM> at a time convenient for that VSAT <NUM>, for example, during its typical non-peak hours when processing and memory resources are minimally used.

At each of the M VSATs <NUM> that received the ITR command, upon its run of the flow <NUM> reaching its <NUM> scheduled retraining time, the flow <NUM> can proceed from the "yes" outbranch of <NUM> to <NUM>. For each VSAT <NUM> flow <NUM> at <NUM>, operations can include the VSAT <NUM> selecting, as its BM retraining input data, a percentage of its training data stored in <NUM>. The selecting at <NUM> can use, for example, random sampling. The flow <NUM> can proceed from <NUM> to <NUM>, and perform the retraining using the random sampling at <NUM>. For purposes of description, a completion result of the retraining at <NUM> will be referred to as a "locally updated classifier model. " For implementations in which the originally pushed BM is a deep neural network, the locally updated classifier model can comprise updated model weights for the deep neural network.

Operations at <NUM> and <NUM> can be controlled by the FL client <NUM>, the RTR logic <NUM>, or both, and can be controlled by other processing resources of the VSAT <NUM>, for example, as described in reference to <FIG>.

Features and benefits of selecting, as retraining input data, a percentage of the training data stored in <NUM> during DRN instead of the entire training data include obviating or significantly reducing impact of not knowing with <NUM>% certainty the correctness of the classification results used at <NUM> for labeling the training data. In other words, there can be a percentage error rate in the labeling of training data as being IoT or non-IoT and, for IoT devices, some percentage error rate in the labeling of the IoT device type. The flow <NUM> taking a sampling, for example <NUM>%, of the training data for retraining the current model obviate or significantly reducing impact of the labeling error. The <NUM>% sampling is only an example and is not intended as a limitation of practices according to this disclosure and is not a statement of preference. Without subscribing to any particular scientific theory, the obviating or significant reduction of such labeling error can be provided by the random sampling obtained at <NUM> including some correct (mostly correct) and some incorrect classifications, and when this repeated retraining based on this data is done across, for example, hundreds of thousands of VSATs <NUM>, the resulting locally updated classifier model will be an improvement over the originally pushed baseline model, and over each subsequently pushed new centralized classifier model.

Upon such completion of the retraining at <NUM>, the flow <NUM> can proceed from <NUM> to <NUM>, at which the VSAT <NUM> can perform operations of uploading the locally updated classifier model to the FL server <NUM>. In certain applications, at one or more of the VSATs <NUM>, the uploading at <NUM> can be performed when the locally updated classifier model is complete, and can be repeated, for example, at non-peak hours when the network utilization is at its lowest.

Corresponding to the uploading at <NUM>, operations at the FL server <NUM> can include receiving, e.g., at the URBM logic <NUM>, the locally updated classifier model. As described earlier, associated with each upload can be an incrementing of a counter. For purposes of description the counter will be referred to as "uploaded locally updated classifier counter" (not separately visible in <FIG>. In an implementation there can be a threshold for the count, at which the FL server <NUM> can perform a combining of the locally updated classifier models. The threshold can be, for example, a percentage of the VSATs <NUM> running the FL client <NUM>, i.e., to which the ITR command was sent at <NUM>. For purposes of description the threshold will be alternatively referred to as "centralized classifier update threshold" or "CT. " Block <NUM> shows the operation determining if the uploaded locally updated classifier counter has reached CT.

The total time required for the URBM logic <NUM> the CT uploaded locally updated classifier models can be dependent on factors such as, for example, IoT device activity statistics at the VSATs <NUM>, the numeric value of CT, and particular retraining scenarios at the VSATS <NUM>. Examples can include approximately a day, multiple days, and less than a full day.

Upon reaching CT, the flow <NUM> can proceed from <NUM> to <NUM> where operations, for example at the FL server <NUM>, can combine the population of CT uploaded locally updated classifier models to create an updated centralized classifier model. Operations at <NUM> can be performed, for example, by the FL server CUBM logic <NUM>.

Assuming the originally pushed BM is a deep neural network, each of the uploaded locally updated classifier models, e.g., <FIG> VSAT CLC <NUM> can include, as described above, updated model weights for the deep neural network. In such neural network implementations, operations at <NUM> can include averaging the weights of each link of the deep neural network reported by each VSAT. In addition to a simple average, other forms of statistical summaries for combining the weights will also be tried.

Optionally can proceed directly from <NUM> to <NUM>, i.e., automatically download new model. Alternatively, can proceed from <NUM> to <NUM>. At <NUM> the new model can be passed through a battery of automated test on well-known new data collected from the lab. If the new model performs better than the current model, the new model can be marked as a candidate for download, if conditions are met, can be pushed to the VSATs as the new centralized classifier model.

In an implementation, operations at <NUM> can include applying hysteresis filtering. The hysteresis filtering can condition the pushing of the new model as a new centralized classifier model, on the new model being more than a hysteresis threshold improvement over the current centralized classifier model. Benefits can include, but are not limited to, prevention of excess toggling between new and old models.

<FIG> is a simplified schematic showing an example configuration of a system <NUM> combination of IoT and non-IoT devices, in one or more implementations of a system or portions of a system in accordance with <FIG>, <FIG>, <FIG>, <FIG> or <FIG>. The system <NUM> can include the IoT server <NUM> described above, or an IoT cloud server resource <NUM>, or both, connected through the Internet <NUM> to a gateway <NUM>. The gateway <NUM> can be, for example, a combination of the IP gateway <NUM> and satellite GW <NUM> described above. The gateway <NUM> can connect to a radio frequency transmitter <NUM> that can communicate via forward uplink/reverse downlink <NUM> to a satellite resource <NUM>, which can communicate via forward downlink/reverse uplink <NUM> to a VSAT terminal <NUM>. The VSAT terminal <NUM> can include a hub/modem <NUM>, which can interface via a wired link <NUM> to a smart television <NUM> and a camera <NUM>. The hub/modem <NUM> can interface vie wireless link or links <NUM> with example devices such as a smartphone <NUM>, an IoT lightbulb <NUM>, various IoT healthcare devices <NUM>, an IoT water detector <NUM>, and a printer <NUM>.

The system <NUM> can include, coupled to the hub/modem <NUM>, VSAT blocks of the <FIG> VSAT <NUM> and can include, coupled to the Internet <NUM>, the FL server <NUM> of the <FIG> system <NUM>, and can include the <FIG> network management system <NUM>. In an example operation, the feature monitor <NUM> can monitor traffic, e.g., via the hub/modem <NUM> and, by applying monitored traffic features to the centralized classifier local copy <NUM>, can classify different ones of the above-identified example devices. The classification can include between being an IoT device and a non-IoT device and, if an IoT device, can classify the IoT device type. The VSAT BW management logic <NUM> can then assign IoT device type-specific QoS and assign corresponding VSAT uplink BW and uplink access priority. Example operations can therefore include, e.g., based on traffic features such as low packet count, the VSAT's centralized classifier local copy <NUM> classifying the IoT light bulb <NUM> as a light bulb type IoT device, and the VSAT BW management logic <NUM> assigning an appropriate QoS. The QoS, for the light bulb type IoT device, can include a low guaranteed bandwidth, low priority, and therefore relatively large guaranteed minimum latency, and relatively high tolerance of dropped packets. The hub/modem <NUM> can also be implemented with a QoS based control of hub bandwidth allocation and user device access priority to hub resources, such as described in reference to <FIG> blocks <NUM> and <NUM>. In such an implementation, the QoS determined by the VSAT BW management logic <NUM> can be provided to the hub BW/priority manager <NUM>. The manager <NUM> can respond by operations such as, but not limited to, assigning the traffic associated with the light bulb IoT device to a low priority queue among the hub/LAN priority queues <NUM>. Example operations of the system <NUM> can also include, based on characteristic packet statistics, classifying the IoT healthcare devices <NUM> and assigning an appropriate QoS, and allocating corresponding VSAT uplink bandwidth and access priority. The QoS and allocated uplink bandwidth and access priority can be, for this example, a guaranteed low delay, high access priority, and minimal tolerance of dropped packets. In an implementation of the hub/modem <NUM> that include the hub/LAN priority queues <NUM>, and hub BW/priority manager <NUM>, or equivalents thereto, the described QoS can be provided to the hub/modem <NUM>, for corresponding allocation of bub resources.

The system <NUM> can run the FL client <NUM>, and operations applied can include receiving the centralized classifier local copy <NUM>, for example, from the BML logic <NUM> of the ML server <NUM>, receiving a retraining instruction from the network management system <NUM> and, in response, generating a training data <NUM>, and then scheduling and performing retraining operations.

<FIG> is a block diagram illustrating a computer system <NUM> upon which aspects of this disclosure may be implemented, such as, but not limited to, particular logic blocks described in reference to <FIG>. It will be understood that logic blocks illustrated in <FIG> represent functions, and do not necessarily correspond to particular hardware on a one-to-one basis. The computer system <NUM> can include a data processor <NUM>, instruction memory <NUM>, and a general-purpose memory <NUM>, coupled by a bus <NUM>.

The instruction memory <NUM> can include a tangible medium retrievably storing computer-readable instructions that, when executed by the data processor <NUM>, cause the processor to perform operations, such as described in reference to <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The computer system <NUM> can include supervised training logic <NUM>. Can include training data storage <NUM>, test data storage <NUM>. Can include machine learning classifier <NUM>; un-supervised training logic <NUM>; federated learning client <NUM>. The computer system <NUM> can also include a communications interface <NUM>, configured to interface with a local network <NUM> for accessing a local server <NUM>, and to communicate through an Internet service provider (ISP) <NUM> to the Internet <NUM>, and access a remote server <NUM>. The computer system <NUM> can also include a display <NUM> and a user interface <NUM>, such as a touchscreen or keypad.

The term "machine-readable medium" as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. Forms of machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

In some examples implemented using computer system <NUM>, various machine-readable media are involved, for example, in providing instructions to processor <NUM> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks. Volatile media includes such dynamic memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <NUM>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infra-red data communications. All such media must be tangible to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine.

Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor <NUM> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over, for example, a telephone line using a modem. A modem local to computer system <NUM> can receive the data on the telephone line and use, for example, an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus <NUM>. Bus <NUM> can carry the data to the instruction memory <NUM>, from which processor <NUM> can retrieve and execute the instructions.

The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims when interpreted in light of this specification and the prosecution history that follows and to encompass all structural and functional equivalents.

Claim 1:
A VSAT system for fingerprint based detection and classification of Internet of Things, IoT, device type, and adaptive allocation and access priority to satellite link bandwidth, comprising
a processor (<NUM>); and
a memory (<NUM>), coupled to the processor (<NUM>), storing executable instructions that, when executed by the processor, cause the processor to:
monitor a link traffic and generate a corresponding feature data,
classify the device (<NUM>), based at least in part on applying a machine learning classifier to at least a portion of the feature data, between being and not being an IoT device of a particular IoT device type; and
in response to classifying the device as the IoT device (<NUM>) of the particular IoT device type to:
assign an IoT device type-specific quality of service, QoS, for carrying a traffic associated with the IoT device, and
allocate, for traffic associated with the IoT device, resources of the link in accordance with the assigned IoT device type-specific QoS;
wherein to classify the device between being and not being an IoT device (<NUM>) of the particular IoT device type includes to:
apply the feature data to a first classifier that is configured to classify the device between being an IoT device and being a non-IoT device, and
in response to the first classifier classifying the device as being an IoT device, to:
apply, to a second classifier, an input that is based at least in part on the feature data of the IoT device, the second classifier being configured to classify the IoT device (<NUM>) between being and not being the particular IoT device type.