WO2024047377A1

WO2024047377A1 - Method for converting a data packet to or from an internet of things (iot) protocol

Info

Publication number: WO2024047377A1
Application number: PCT/IB2022/058120
Authority: WO
Inventors: Carla MOURADIAN; Mbarka SOUALHIA
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-08-30
Filing date: 2022-08-30
Publication date: 2024-03-07

Abstract

The disclosure relates to a computer implemented method, an IoT gateway and a non-transitory computer readable media, for converting a data packet to or from an internet of things (IoT) protocol. The method comprises obtaining a plurality of data packets from IoT devices and from applications using different communication protocols. The method comprises training a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data. The method comprises dividing the data packet into the blocks of data using the ML model. The method comprises based on the blocks of data, selecting a conversion rule from a repository of conversion rules, where the conversion rule provides instructions for converting the data packet to or from the IoT protocol.

Description

METHOD FOR CONVERTING A DATA PACKET TO OR FROM AN INTERNET

OF THINGS (IOT) PROTOCOL

TECHNICAL FIELD

[0001] The present disclosure relates to conversion of protocol for internet of things (loT) gateways.

BACKGROUND

[0002] The internet of things (loT) is considered as part of the internet of the future. It is a novel paradigm that is gaining the attention of modern wireless telecommunications. It is present around us as a variety of things or objects such as radio-frequency identification (RFID) tags, sensors, actuators, mobile phones, etc. which are able to interact with each other and cooperate with their neighbors to achieve common goals. loT is used in a large number of applications in a variety of fields such as industry 4.0, smart cities, smart homes, connected cars, industrial manufacturing, healthcare, disaster recovery - to name a few.

[0003] loT devices are heterogeneous and use various application protocols e.g., constrained application protocol (CoAP), message queuing telemetry transport (MQTT), extensible messaging and presence protocol (XMPP), etc.

[0004] Due to the large number of protocols used in the loT domain, gateways are required to enable coordination between applications and heterogeneous, multivendor loT devices, and also among loT devices adopting different protocols. However, the number of loT devices grows every day and so does their diversity. It is predicted that there will be 43 billion loT devices by 2023 and 5 billion cellular loT connections by 2025, this leads to a broad ecosystem of transmission protocols.

[0005] There exist several industrial loT gateways in the market to enable coordination and protocol conversion between loT devices and applications using them, e.g., Eurotech loT gateways, Adlink loT gateways, Dell edge loT gateways. Although these gateways support some loT devices protocols, these protocols are predefined, and their configuration files are defined in advance.

[0006] Thus, it is difficult and expensive to upgrade them when new brands of loT devices with new protocols are deployed.

[0007] There exists no solution that is prepared for the expectable emerging diversity in the loT world due to lack of agility and scale. SUMMARY

[0008] Therefore, it is of interest to have an adaptive, automated, and intelligent protocol conversion in loT gateways to ensure the mapping of data between loT applications and the required devices to perform the applications requests. This should be done in a way that considers the diverse protocols of existing loT devices and the newly dynamically added ones, with new protocols.

[0009] There is provided a computer implemented method for converting a data packet to or from an internet of things (loT) protocol. The method comprises obtaining a plurality of data packets from loT devices and from applications using different communication protocols. The method comprises training a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data. The method comprises dividing the data packet into the blocks of data using the ML model. The method comprises based on the blocks of data, selecting a conversion rule from a repository of conversion rules, where the conversion rule provides instructions for converting the data packet to or from the loT protocol.

[0010] There is provided an internet of things (loT) gateway for converting a data packet to and from an loT protocol. The loT gateway comprises processing circuits and a memory, the memory containing instructions executable by the processing circuits. The loT gateway is operative to obtain a plurality of data packets from loT devices and from applications using different communication protocols. The loT gateway is operative to train a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data. The loT gateway is operative to divide the data packet into the blocks of data using the ML model. The loT gateway is operative to, based on the blocks of data, select a conversion rule from a repository of conversion rules, wherein the conversion rule provides instructions for converting the data packet to and from the loT protocol. [0011] There is provided a non-transitory computer readable media having stored thereon instructions for converting a data packet to and from an internet of things (loT) protocol, the instructions comprising any of the steps described herein.

[0012] The method and loT Gateway and non-transitory computer readable media provided herein present improvements to the way data packet protocol conversion operate. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram illustrating the nodes involved in the intelligent protocol conversion solution.

[0014] Figure 2 is a block diagram illustrating the proposed intelligent protocol conversion system.

[0015] Figure 3 is a flowchart of the method for the proposed intelligent protocol conversion solution.

[0016] Figure 4 is a schematic illustration of a decision tree (DT) model obtained by training a machine learning (ML) model.

[0017] Figure 5 is a block diagram illustrating two protocol conversion methods.

[0018] Figure 6 is a flowchart of a method for converting a data packet to or from an internet of things (loT) protocol

[0019] Figure 7 is a schematic illustration of an loT gateway in which steps and/or method described herein can be executed.

[0020] Figure 8 is a schematic illustration of a virtualization environment in which the different method(s) and apparatus(es) described herein can be deployed.

DETAILED DESCRIPTION

[0021] Various features will now be described with reference to the drawings to fully convey the scope of the disclosure to those skilled in the art.

[0022] Sequences of actions or functions may be used within this disclosure. It should be recognized that some functions or actions, in some contexts, could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both.

[0023] Further, computer readable carrier or carrier wave may contain an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0024] The functions/actions described herein may occur out of the order noted in the sequence of actions or simultaneously. Furthermore, in some illustrations, some blocks, functions or actions may be optional and may or may not be executed; these are generally illustrated with dashed lines.

[0025] At least some aspects of the techniques described herein may be implemented using artificial intelligence, which comprises a variety of techniques as would be apparent to a person skilled in the art, including machine learning techniques. Machine learning techniques include Neural Network (NN), or Artificial Neural Network (ANN), as well as many other techniques.

[0026] A solution for an adaptive and automated protocol conversion for loT gateways is proposed herein. The proposed protocol conversion is intelligent; it can adaptively coordinate the operations between the loT devices and the applications. [0027] The solution provides an automated and intelligent protocol conversion to handle the diverse protocols and technologies used by the loT devices and the applications hosted in edge/cloud. This is done using historical packet data. The proposed protocol conversion solution builds machine learning models and identifies interpretation/conversion rules to be used in order to perform automated protocol conversion. It also provides continuous learning through adding the newly generated protocol conversion rules to a repository to be reused in the future.

[0028] This solution provides a self-adaptive and automated protocol conversion system and methods that allow coordination between loT devices and loT applications in edge/cloud. The proposed solution is responsible for analyzing conversion specifications/requirements given by the user, profiling historical packet data to build machine learning models and identifying conversion rules, converting packet data from an input protocol to an output protocol and storing and publishing new conversion rules that are discovered.

[0029] The solution provides the following advantages. It provides an automated technique to dynamically coordinate the operations between loT applications in the edge/cloud and devices to improve the performance of loT applications and loT devices. It provides an automated technique to understand and convert different protocols of loT applications and devices to ensure communication between (to and from) loT and the edge/cloud. It provides continuous learning and building of knowledge-based repository about different protocols (devices, application), protocols conversion, and devices properties (interface, connectivity, newly deployed devices...). It provides the possibility of updating existing gateways on the fly with new protocol conversion capabilities.

[0030] Figure 1 presents how the proposed intelligent protocol conversion system 10 intersects or resides in existing loT gateways 15. The proposed solution can be integrated with any existing loT gateways. [0031] It should be noted that the loT gateways can be deployed at different places. For example, the loT gateways could be deployed at the edge due to the amount of data generated from loT devices that need to be processed and analyzed. Instead of sending all data over the public internet to a datacenter, the gateway at the edge can gather and process loT data at the edge, closer to the devices (e.g., filtering and aggregation), thus saving bandwidth that would be required to send massive amount of data to a data center or public cloud.

[0032] Figure 2 illustrates the proposed intelligent Protocol Conversion system 10. It comprises a protocol converter 20 and conversion rules repository 25.

[0033] The system 10 takes as input the historical data about previous packets and their protocols, live packet data received from a gateway manager, and interpretation or conversion requirements provided by a user to describe some specifications to be followed when performing the interpretation. The requirements describe specifications, they can be, for instance, the given protocol’s number of blocks, expected header size/range, payload size, maximum packet length, etc. It generates as output a protocol conversion function with a specific conversion mechanism for the given protocols. This protocol conversion functionality can be deployed in an loT gateway. For instance, a protocol conversion function can comprise the following steps. Stepl, the protocol conversion function gets a live packet as input. Step 2, the protocol conversion function uses a selected trained model that gave the best performance during the training. Step 3, according to the model, the protocol conversion function identifies the “division” that is consistent with the conversion rules found in the conversion rules repository. Step 4, if the identified “division” is consistent with the rules, the protocol conversion function proposes a conversion. Step 5, the protocol conversion function converts the received packet to the destination protocol. For that, the protocol conversion function puts the received packet in the destination format (header, payload, etc.). Step 6, the protocol conversion function sends the converted packet to the destination.

[0034] The protocol converter 20 is mainly responsible for performing protocol interpretation/conversion when requested by a gateway manager in a gateway domain. Using training data (previous packets), the protocol converter 20 builds different ML models to learn the different patterns in the splitted packets (the packets are splitted in training and testing data). [0035] Given conversion requirements and training data, the protocol converter 20 also identifies conversion rules to find some rules about the size of each block in the packet (e.g., header, size of the packet, payload, token, etc.) and their specifications. [0036] When receiving a request to perform protocol conversion between two protocols, the protocol converter 20 uses the selected model to identify the corresponding divisions of the live packet. Next, it checks whether the proposed divisions are consistent with the conversion rules that could be found in the conversion rules repository 25.

[0037] The conversion rules repository 25 includes data and rules about protocol mapping between the different protocols used on the selected device. The conversion rules repository 25 includes a different pattern of divisions between protocols and how packets could be divided to perform protocol conversion.

[0038] Figure 3 is a flowchart illustrating the working of the intelligent protocol converter 20, which presents the different steps followed to perform protocol conversion. The inputs of the protocol converter 20 are the historical data 27 about previous packets and their protocols, live packet data 28 received from a gateway manager, and interpretation/conversion requirements 29 provided by a user to describe some specifications to be followed when performing the interpretation. [0039] Given the protocol names, the protocol converter 20 first identifies, step 31, the divisions of the packet following their parsing rules (e.g., MQTT, CoAP parsing rules) and determines the different parts of each packet (e.g., header, packet length, payload, etc.).

[0040] The protocol converter 20 splits, step 32, the received data into testing and training data following splitting requirements (e.g., 70% training data and 30% testing data or 80% training data and 20% testing data, etc.).

[0041] Using training data, the protocol converter 20 builds, step 33, different ML models to learn the different patterns in the splitted packets. In this step, different supervised machine learning methods can be used, including K-NN, Random Forest (RF), Decision Tree (DT), Support Vector Machine (SVM), etc. To train the different ML models, the historical previous packets with known divisions are used.

[0042] Then, for instance, a decision tree model can be trained using the training data. Such training includes two parts: induction and pruning. Once trained, the decision tree is able to define the correct divisions of a live packet according to the trained model. Similarly, random forest model, support vector machine, etc. can be trained. Then, the performance of the decision tree model can be improved using the testing data. The performance can be measured in terms of accuracy, recall, precision, Flscore.

[0043] Given the testing data, the protocol converter 20 measures, step 34, and evaluates the performance of the trained ML model in terms of accuracy, recall, precision, Fl -score.

[0044] Next, the protocol converter 20 identifies, step 35, the model having the best performance to be used to identify the appropriate divisions for the packets when receiving live data. This is done given conversion requirements and training data. The main idea behind this step is to find some rules about the size of each block in the packet (e.g., header, size of the packet, payload, token, etc.) and their specifications. [0045] When receiving a request from a gateway manager to perform protocol conversion of a live packet, the protocol converter 20 uses the selected model to identify the corresponding divisions of the live packet. Next, it checks, step 36, whether the proposed divisions are consistent with the conversion rules that could be found in the conversion rules repository 25.

[0046] When the proposed divisions are consistent with the conversion rules, it adds, step 37, the new rules to the conversion rules repository 25 to be reused in the future. [0047] Otherwise, it notifies, step 38, the user to check the proposed divisions and modifies it. Accordingly, it adds the modified conversions to the list of conversion rules repository 25.

[0048] An illustrative example will now be presented, considering the packet examples as shown below that could be used to train the ML models and identify conversion rules. The example illustrates the conversion steps and how the conversion is done by the protocol converter 20.

[0049] The first step consists of analyzing the historical data. The packet examples contain information about the size (in byte/bit) of the most common parts in packets according to their protocol names and the total size of packets. In the given example, only 2 types of protocol are selected: CoAP and MQTT. The data could be used to train ML models including Decision Tree (DT) model that could give, as an example, the tree illustrated in Figure 4.

[0050] The data could also be used to identify conversion rules. An example of generated rules could be:

Size of the header should be between <X, Y> values Size of payload should be between <X,Y> values Control header size is usually 1 byte If total packet length > X, then it is a CoAP If X ==4: msg empty

If total packet length > Y, then it is MQTT Etc.

[0051] Given these conversion rules and the tree obtained from the DT model, the protocol converter 20 takes as an input a packet and identifies its divisions/parts. So, it checks the total packet length in the rules and then finds the different sizes of these parts from the rules and the DT tree.

[0052] Previously, details were presented of the working of the protocol converter 20 when receiving protocol conversion requests from loT applications running in edge/cloud or a gateway manager. This represents a “reactive” protocol converter. As shown in Figure 5, the protocol converter 20 could have two modes: “reactive” 20 and “proactive” 20a.

[0053] In the proactive mode, the protocol conversion functionality could be generated before the arrival of a request. This can be triggered by a gateway application predictor 55, responsible for collecting statistics about the type of loT application and performing load predict! on/analy sis to know in advance the type of the received requests over time and the type/specifications of the requested loT devices. The proactive converter could generate a protocol conversion functionality and deploy it in advance to gain time when receiving the loT requests.

[0054] The first step for the proactive mode, requires collecting data about previous loT requests and analyzing the data: the type of applications sending the requests (e.g., memory-intensive, central processing unit (CPU)-intensive application, gaming application, video-conferencing application, etc.), the arrival of the requests (predicting the application load), etc. Next, the proactive protocol converter 20a generates rules about the usage of the devices for these loT requests when deploying/executing the requested gateway functionalities. This step is done to know which application will use which loT devices and to allocate them properly to make better use of the loT devices resources. This information/data is then saved in the “devices repository”. The proactive protocol converter 20a also analyzes the performance of the applications when using the loT devices to filter the loT devices based on their performance and prioritize the ones having better performance (e.g., execution time, delay, energy consumption, data exchange, etc.). According to these inputs, the proactive protocol converter 20a can generate the appropriate protocol conversion functionality in advance.

[0055] The solution presented herein could be deployed in different loT applications and domains that require integration and cooperation between different devices and applications in edge/cloud environment. Hence, it could improve the execution of loT requests submitted by loT applications and the coordination between loT applications, loT gateways, loT devices, etc.

[0056] It should be noted that methods and steps described herein are, generally, computer implemented methods and steps. The term computer may be interpreted as having different meanings, such as explained next, for example.

[0057] Figure 6 illustrates a computer implemented method 60 for converting a data packet to or from an internet of things (loT) protocol. The method comprises obtaining, step 61, a plurality of data packets from loT devices and from applications using different communication protocols. The method comprises training, step 62, a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data. The method comprises dividing, step 63, the data packet into the blocks of data using the ML model. The method comprises based on the blocks of data, selecting, step 64, a conversion rule from a repository of conversion rules, wherein the conversion rule provides instructions for converting the data packet to or from the loT protocol.

[0058] The method may further comprise applying, step 65, the conversion rule to the data packet, thereby converting the data packet to or from the loT protocol. [0059] The date packets may be obtained during a configurable period of time, which may vary from minutes to months, depending on the availability and the frequency of the data packets. The data packets have known divisions in blocks of data.

[0060] Training the ML model may comprise training a plurality of ML models. The plurality of ML models may comprise any two or more ML models of any type selected within: K-nearest neighbors (K-NN), Random Forest (RF), Decision Tree (DT) and Support Vector Machine (SVM).

[0061] The method may further comprise measuring a performance of each of the plurality of ML models, using a second portion of the plurality of data packets. The ML model used for dividing the data packet into the blocks may be selected among the plurality of ML models, having the best performances according to conversion requirements.

[0062] The method may further comprise collecting statistics about the applications and associated requests directed to the loT devices. The method may further comprise analysing the collected statistics and making load predictions for different types of requests. Selecting the conversion rule may further be based on the load predictions. [0063] The conversion rule is for converting from a given protocol and may comprise expected sizes and specifications for the blocks of the data packet including a number of blocks, an expected header size, a payload size and a maximum packet length. The selection of the conversion rule may further comprises comparing the blocks of data of the data packet and finding a conversion rule in the conversion rules repository that is consistent with the divisions of the data packet.

[0064] The method may further comprise adding a new conversion rule to the repository of conversion rules, for converting from a given protocol, by following parsing rules for the given protocol and determining corresponding divisions of the data packet.

[0065] The method may further comprise storing and publishing new conversion rules that are discovered. The ML model should be able to define the splitting of any new type of data packet it encounters. The ML models may be continuously trained and during the training, when defining the division of the data packed in blocks of data, new conversion rules may be identified. For instance, considering if a new type of packets is encountered during the continuous training, then a new conversion rule can be defined. For instance, if the ML model defines a division that indicates that the header size is 4 for a packet size of 30, if this division is consistent with the rules (e.g., header size should be between 2 and 8), then a new rule may be added that indicates: “header size for a 30-size packet is 4”. The new rule is consistent with the rules in the repository, and it adds a more specific new rule.

[0066] Referring to figure 7, there is provided an loT gateway (HW) 15, in which functions and steps described herein can be implemented.

[0067] The loT gateway 15 may be implemented (e.g., virtually) as part of a server, network node, radio base station, or other computing device which may be part of a cloud computing system, edge computing system, or which may be a standalone device. The loT gateway applies the method described herein and convert data packets to and from loT devices between different communication protocols to enable loT devices to communicate between each other and with applications.

[0068] The loT gateway 15 comprises processing circuitry 73 and memory 75. The memory 75 can contain instructions executable by the processing circuitry 73 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein.

[0069] The loT gateway 15 may also include non-transitory, persistent, machine- readable storage media 77 having stored therein software and/or instruction 79 executable by the processing circuitry 73 to execute functions and steps described herein. The loT gateway may also include network interface(s) and a power source. [0070] The instructions 79 may include a computer program for configuring the processing circuitry 73. The computer program may be stored in a physical memory local to the device, which can be removable, or it could alternatively, or in part, be stored in the cloud. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0071] Referring to figure 8, there is provided a virtualization environment 80 in which functions and steps described herein can be implemented.

[0072] The virtualization environment 80 (which may go beyond what is illustrated in figure 8), may comprise systems, networks, servers, nodes, devices, etc., that are in communication with each other either through wire or wirelessly, e.g., through a network interface component (NIC) comprising physical network interface(s). Some or all of the functions and steps described herein may be implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, containers, etc.) executing on one or more physical apparatus in one or more networks, systems, environment, etc.

[0073] A virtualization environment provides hardware 81 comprising processing circuitry 83 and memory 85. The memory 85 can contain instructions executable by the processing circuitry 83 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein. [0074] The hardware 81 may also include non-transitory, persistent, machine- readable storage media 87 having stored therein software and/or instruction 89 executable by the processing circuitry 83 to execute functions and steps described herein.

[0075] The instructions 89 may include a computer program for configuring the processing circuitry 83. The computer program may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0076] Referring to figures 7 and 8, there is provided an internet of things (loT) gateway 15, 81 or “virtual appliance”, for converting a data packet to and from an loT protocol. The loT gateway comprises processing circuits and a memory. The memory contains instructions executable by the processing circuits whereby the loT gateway is operative to obtain a plurality of data packets from loT devices and from applications using different communication protocols. The loT gateway is operative to train a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data. The loT gateway is operative to divide the data packet into the blocks of data using the ML model. The loT gateway is operative to, based on the blocks of data, select a conversion rule from a repository of conversion rules, where the conversion rule provides instructions for converting the data packet to and from the loT protocol.

[0077] The packet data may be received by the loT gateway from a gateway manager. As illustrated in figure 8, the loT gateway (virtual appliance) may be deployed at the edge or in a data center or public cloud.

[0078] The loT gateway may be further be operative to collect statistics about the applications and associated requests directed to the loT devices. The loT gateway may further be operative to analyse the collected statistics and make load predictions for different types of requests. The loT gateway may further be operative to generate rules about usage of the loT devices for the different types of requests. The loT gateway may further be operative to allocate the loT devices to the applications. [0079] The allocation of the loT devices may be made by prioritizing loT devices having shorter execution time, shorter execution delay and lower energy consumption. [0080] The loT gateway may further be operative to save the allocation of loT devices to the applications in a device repository.

[0081] The loT gateway is further operative to execute any of the steps described herein.

[0082] There is provided a non-transitory computer readable media 77, 87 having stored thereon instructions for converting a data packet to and from an internet of things (loT) protocol, the instructions comprising any of the steps described herein. [0083] Modifications will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that modifications, such as specific forms other than those described above, are intended to be included within the scope of this disclosure. The previous description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than the preceding description, and all variations and equivalents that fall within the range of the claims are intended to be embraced therein. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMS A computer implemented method for converting a data packet to or from an internet of things (loT) protocol, comprising: obtaining a plurality of data packets from loT devices and from applications using different communication protocols; training a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data; dividing the data packet into the blocks of data using the ML model; and based on the blocks of data, selecting a conversion rule from a repository of conversion rules, wherein the conversion rule provides instructions for converting the data packet to or from the loT protocol. The method of claim 1, further comprising applying the conversion rule to the data packet, thereby converting the data packet to or from the loT protocol. The method of claim 1, wherein the date packets are obtained during a configurable period of time. The method of claim 1, wherein the data packets have known divisions in blocks of data. The method of claim 1, wherein training the ML model comprises training a plurality of ML models. The method of claim 5, wherein the plurality of ML models comprise any two or more ML models of any type selected within: K-nearest neighbors (K-NN), Random Forest (RF), Decision Tree (DT) and Support Vector Machine (SVM). The method of claim 5, further comprising: measuring a performance of each of the plurality of ML models, using a second portion of the plurality of data packets; and wherein the ML model used for dividing the data packet into the blocks is selected among the plurality of ML models, having the best performances according to conversion requirements.

8. The method of claim 1, further comprising: collecting statistics about the applications and associated requests directed to the loT devices; and analysing the collected statistics and making load predictions for different types of requests; wherein selecting the conversion rule is also based on the load predictions.

9. The method of claim 1, wherein the conversion rule is for converting from a given protocol and comprises expected sizes and specifications for the blocks of the data packet including a number of blocks, an expected header size, a payload size and a maximum packet length.

10. The method of claim 9, wherein selecting the conversion rule further comprises comparing the blocks of data of the data packet and finding a conversion rule in the conversion rules repository that is consistent with the divisions of the data packet.

11. The method of claim 1, further comprising adding a new conversion rule to the repository of conversion rules, for converting from a given protocol, by following parsing rules for the given protocol and determining corresponding divisions of the data packet.

12. The method of claim 1, further comprising storing and publishing new conversion rules that are discovered.

13. An internet of things (loT) gateway for converting a data packet to and from an loT protocol, comprising processing circuits and a memory, the memory containing instructions executable by the processing circuits whereby the loT gateway is operative to: obtain a plurality of data packets from loT devices and from applications using different communication protocols; train a machine learning (ML) model to divide the data packet into blocks of data, using a first portion of the plurality of data packets as training data; divide the data packet into the blocks of data using the ML model; and based on the blocks of data, select a conversion rule from a repository of conversion rules, wherein the conversion rule provides instructions for converting the data packet to and from the loT protocol.

14. The loT gateway of claim 13, wherein the packet data is received from a gateway manager.

15. The loT gateway of claim 13, wherein the loT gateway is deployed at the edge or in a data center or public cloud.

16. The loT gateway of claim 13, further operative to collect statistics about the applications and associated requests directed to the loT devices; analyse the collected statistics and make load predictions for different types of requests; generate rules about usage of the loT devices for the different types of requests; and allocate the loT devices to the applications.

17. The loT gateway of claim 16, wherein the allocation of the loT devices is made by prioritizing loT devices having shorter execution time, shorter execution delay and lower energy consumption.

18. The loT gateway of claim 16, further operative to save the allocation of loT devices to the applications in a device repository.

19. The loT gateway of claim 13, further operative to execute any of the steps of claims 2 to 12. A non-transitory computer readable media having stored thereon instructions for converting a data packet to and from an internet of things (loT) protocol, the instructions comprising any of the steps of claims 1 to 12.