Sign In to Follow Application
View All Documents & Correspondence

System And Method For Managing Network Resources By Mqtt Encryption

Abstract: The present disclosure relates to a system and a method for managing network resources by a Message Queuing Telemetry Transport (MQTT) encryption. The system registers one or more computing devices with an embedded application to a network, encrypts application data corresponding to the embedded application based on registration of the one or more computing devices, optimizes at least one network parameter of a plurality of network parameters to secure the encrypted application data at a server, and sends the secured application data to the server by establishing MQTT connection with the server.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
15 July 2022
Publication Number
03/2024
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application

Applicants

JIO PLATFORMS LIMITED
Office-101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.

Inventors

1. KUMAR, Ranjit Ma
Flat No KV-105, Kanha Vertical Gopal Vihar, Jabalpur – 482002, Madhya Pradesh, India.
2. RAHUL, Kumar
D-13, Sangam Complex, Lake Town, Kolkata – 700089, West Bengal, India.
3. MARUF, Kazim Hanif
202, Plot 104, Krishna Sarang Galaxy, Sec 18, Ulwe, Navi Mumbai - 410206, Maharashtra, India.
4. NAYAK, Pintu
Rajalabandh, Near Baharagora College - 832101, Jharkhand, India.

Specification

DESC:RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent filed or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.

FIELD OF DISCLOSURE
[0002] The embodiments of the present disclosure generally relate to the field of wireless communication, and more particularly, to a system and a method for reducing traffic overhead, processing time, and resource utilization on a bandwidth constraint network by using alternative methods of securing application data and including additional optimizations on Message Queuing Telemetry Transport (MQTT).

BACKGROUND OF DISCLOSURE
[0003] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0004] In general, bandwidth of a cellular network, especially a Narrowband – Internet of Things (NB-IoT) network has to be efficiently utilized to make an IoT solution work flawlessly, without adding unnecessary overhead on the network. Conventionally, unnecessary load may be accumulated on the network by using outdated, chatty protocols, security algorithms, retry mechanisms and un-optimized polling mechanisms used by a client and a server. The unnecessary load may be due to a Transport Layer Security (TLS) provided over the MQTT. The TLS adds unnecessary overheads, increases processing time and consumes network resources. The below mentioned method illustrates in detail how much (or little) processing, latency, and traffic overhead the TLS adds. The overhead from the TLS can be divided into several different aspects:
• Traffic overhead from TLS handshake,
• Latency overhead from TLS handshake,
• Traffic overhead from TLS record layer,
• Processing overhead from TLS handshake, and
• Processing overhead from TLS record layer.
[0005] The TLS handshake typically adds 4-7 kB of traffic overhead and others as mentioned below.
• Per-packet overhead 21 bytes
• TLS header 5 bytes
• TLS trailer 16 bytes
• HMAC-MD5 16 bytes
[0006] Therefore, the process is very costly in terms of Central Processing Unit (CPU) utilization and bandwidth. Further, the TLS affects performance significantly, especially CPU usage during the handshake. Once MQTT clients are connected, the overhead is negligible.
[0007] There is, therefore, a need in the art to provide a method and a system to reduce traffic overhead, processing time, and resource utilization on a bandwidth constraint network by overcoming the shortcomings of the existing prior arts.

OBJECTS OF THE PRESENT DISCLOSURE
[0008] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.
[0009] It is an object of the present disclosure to provide a system that efficiently utilizes bandwidth of a cellular network, especially a Narrowband-Internet of Things (NB-IOT) network to make an IoT solution work flawlessly, without adding unnecessary load over the network.
[0010] It is an object of the present disclosure to provide a system that secures application data over a Transport Layer Security (TLS) and reduces consumption of network resources and time in the whole process of securing application data over TLS.
[0011] It is an object of the present disclosure to provide a system that reduces central processing unit (CPU) usage during handshake in a call flow with an embedded application having TLS implemented and seeking to send the application data to a server.

SUMMARY
[0012] This section is provided to introduce certain objects and aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0013] In an aspect, the present disclosure relates to a system for managing network resources by Message Queuing Telemetry Transport (MQTT) encryption. The system includes one or more processors, and a memory operatively coupled to the one or more processors. The memory includes processor-executable instructions, which on execution, cause the one or more processors to register one or more computing devices with an embedded application to a network, encrypt application data corresponding to the embedded application based on registration of the one or more computing devices, optimize at least one network parameter of a plurality of network parameters to secure the encrypted application data, and send the secured application data to a server by establishing an MQTT connection with the server in response to optimization of the at least one network parameter of the plurality of network parameters.
[0014] In an embodiment, the one or more processors may encrypt the application data corresponding to the embedded application by being configured to determine whether the one or more computing devices with the embedded application are enabled based on the registration of the one or more computing devices to the network, collect the application data corresponding to the embedded application from one or more sensors of the one or more computing devices in response to a determination that the one or more computing devices with the embedded application is enabled; convert the application data corresponding to the embedded application into a predefined format; and encrypt the application data corresponding to the embedded application via an encryption key based on the conversion of the application data.
[0015] In an embodiment, the one or more processors may establish the MQTT connection with the server by being configured to: send an MQTT Connect Command to the server, receive an MQTT Connect Accept response from the server, establish a Transmission Control Protocol (TCP) connection with the server in response to receiving the MQTT Connect accept response from the server, and establish the MQTT connection with the server in response to establishing the TCP connection with the server.
[0016] In an embodiment, the memory includes processor-executable instructions, which on execution, may cause the one or more processors to send an application data subscription request to the server, receive an application data subscription accept response from the server, and send the encrypted application data to at least one subscriber associated with at least one computing device in response to receiving the application data subscription accept response from the server.
[0017] In an embodiment, the secured application data may be decrypted via a decryption key by the at least one subscriber associated with at least one computing device.
[0018] In an embodiment, the at least one network parameter of the plurality of network parameters may include, but not limited to, a bandwidth, a payload, a Quality of service (QoS), a topic length, and a message size.
[0019] In another aspect, the present disclosure relates to a method for managing network resources by Message Queuing Telemetry Transport (MQTT) encryption. The method includes registering, by a processor associated with a system, one or more computing devices with an embedded application to a network, encrypting, by the processor, application data corresponding to the embedded application based on registration of the one or more computing devices, optimizing, by the processor, at least one network parameter of a plurality of network parameters to secure the encrypted application data, and sending, by the processor, the secured application data to a server by establishing an MQTT connection with the server.
[0020] In an embodiment, encrypting, by the processor, the application data corresponding to the embedded application may include determining, by the processor, whether the one or more computing devices with the embedded application is enabled based on the registration of the one or more computing devices to the network, collecting, by the processor, the application data corresponding to the embedded application from one or more sensors of the one or more computing devices in response to determining that the one or more computing devices with the embedded application is enabled, converting, by the processor, the application data corresponding to the embedded application into a predefined format, and encrypting, by the processor, the application data corresponding to the embedded application via an encryption key based on conversion of the application data.
[0021] In an embodiment, establishing, by the processor, the MQTT connection with the server includes sending, by the processor, an MQTT Connect Command to the server, receiving, by the processor, an MQTT Connect accept response from the server, establishing, by the processor, a Transmission Control Protocol (TCP) connection with the server in response to receiving the MQTT Connect accept response from the server, and establishing, by the processor, the MQTT connection with the server in response to establishing the TCP connection with the server.
[0022] In an embodiment, the method may include sending, by the processor, an application data subscription request to the server, receiving, by the processor, an application data subscription accept response from the server, and sending, by the processor, the encrypted application data to at least one subscriber associated with at least one computing device in response to receiving the application data subscription accept response from the server.
[0023] In an embodiment, the encrypted application data may be decrypted via a decryption key by the at least one subscriber associated with the at least one computing device.
[0024] In an embodiment, the at least one network parameter of the plurality of network parameters may include, but not limited to, a bandwidth, a payload, a Quality of service (QoS), a topic length and a message size.
[0025] In another aspect, the present disclosure relates to a user equipment. The user equipment includes one or more processors, and a memory operatively coupled to the one or more processors. The memory includes processor-executable instructions, which on execution, cause the one or more processors to encrypt application data corresponding to the embedded application based on registration of the one or more computing devices, optimize at least one network parameter of a plurality of network parameters to secure the encrypted application data at the server, and send the secured application data to a server by establishing a Message Queuing Telemetry Transport (MQTT) connection with the server.

BRIEF DESCRIPTION OF THE DRAWINGS
[0026] The accompanying drawings, which are incorporated herein, and constitute a part of this specification, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that invention of such drawings includes the invention of electrical components, electronic components or circuitry commonly used to implement such components.
[0027] FIG. 1 illustrates an exemplary network architecture (100) in which or with which system (110) of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure.
[0028] FIG. 2 illustrates an exemplary block diagram (200) of the system (110), in accordance with an embodiment of the present disclosure.
[0029] FIG. 3 illustrates an exemplary representation (300) of a typical call flow with an embedded application having TLS implemented and seeking to send application data to the server.
[0030] FIG. 4 illustrates an exemplary representation (400) of CPU utilization for plain TCP vs. TLS.
[0031] FIG. 5 illustrates an exemplary flow mechanism (500) of MQTT Payload encryption, in accordance with an embodiment of the present disclosure.
[0032] FIG. 6 illustrates an exemplary flow mechanism (600) of client to server call flow on MQTT with alternative security methods, in accordance with an embodiment of the present disclosure.
[0033] FIG. 7 illustrates an exemplary flow mechanism (700) of Client to server MQTT call flow (without TLS and other security algorithm), in accordance with an embodiment of the present disclosure.
[0034] FIG. 8 illustrates an exemplary flow mechanism (800) of TLS handshake flow, in accordance with an embodiment of the present disclosure.
[0035] FIG. 9 illustrates an exemplary flow diagram (900) of a process of saving network resources by MQTT method, in accordance with an embodiment of the present disclosure.
[0036] FIG. 10 illustrates an exemplary architecture (1000) of the system (110), in accordance with an embodiment of the present disclosure.
[0037] FIG. 11 illustrates an exemplary block diagram (1100) of a computer system in which or with which embodiments of the present disclosure may be implemented.
[0038] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DETAILED DESCRIPTION
[0039] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0040] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0041] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0042] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0043] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0044] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0045] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
[0046] The present disclosure efficiently utilizes bandwidth of a cellular network, especially a NarrowBand-Internet of Things (NB-IoT) network to make an IoT solution work flawlessly, without adding unnecessary load over the network. Further, the present disclosure secures application data over a Transport Layer Security (TLS) and reduces consumption of network resources and time in the whole process of securing the application data over the TLS. Also, the present disclosure reduces central processing unit (CPU) usage during handshake in a call flow with an embedded application having the TLS implemented and seeking to send the application data to the server.
[0047] Therefore, the present disclosure reduces traffic overhead, processing time, and resource utilization on a bandwidth constraint network by using alternative methods of securing application data and including additional optimizations on Message Queuing Telemetry Transport (MQTT).
[0048] Certain terms and phrases have been used throughout the disclosure and will have the following meanings in the context of the ongoing disclosure.
[0049] The term “NB-IoT” may refer to NarrowBand-Internet of Things network. The NB-IoT enables devices to operate in mobile carrier networks. NB-IoT technology uses low bandwidth signals to communicate within existing Global System for Mobile communication (GSM) and Long-Term Evolution (LTE) technologies. Specially designed devices and sensors are the basic components in NB-IoT systems.
[0050] The term “TLS” may refer to Transport Layer Security that is the most widely used protocol for implementing cryptography on the web. TLS uses a combination of cryptographic processes to provide secure communication over the network.
[0051] The term “TCP” may refer to a Transmission Control Protocol that enables data to be transferred between applications and devices on the network and is used in a TCP Internet Protocol (IP) model. The TCP may break down a message, such as an email, into packets of data to ensure the message reaches its destination successfully and as quickly as possible.
[0052] The term “MQTT” may refer to Message Queuing Telemetry Transport protocol that is a messaging protocol for restricted low-bandwidth networks and extremely high-latency IoT devices. Since MQTT is specialized for low-bandwidth, high-latency environments, MQTT is an ideal protocol for machine-to-machine (M2M) communication. It is light weight, open, simple, and designed so as to be easy to implement.
[0053] The term “QoS” may refer to Quality of Service. QoS guarantees that a message is delivered at least one time to a receiver. A sender stores the message until it gets a PUBACK packet from the receiver that acknowledges receipt of the message. The message may be sent or delivered multiple times.
[0054] The term “payload” may refer to an application-specific content of an MQTT packet. The payload may contain the actual content of the message. MQTT may be data-agnostic. MQTT may send images, text in any encoding, encrypted data, and virtually every data in binary.
[0055] The term “topic” may be an MQTT-specific form of addressing that allows MQTT clients to share information.
[0056] The term “Topic Alias” may be an MQTT feature that allows MQTT clients to define an integer value that the client uses as a substitute for the name of a topic. Use of a Topic alias in place of a Unicode Transformation Format (UTF)-8 string topic name may reduce the size of the PUBLISH package.
[0057] The various embodiments throughout the disclosure will be explained in more details with reference to FIGs. 1-11.
[0058] Referring to FIG. 1 that illustrates an exemplary network architecture (100) in which or with which a system (110) of the present disclosure may be implemented. As illustrated in FIG. 1, by way of example and not by not limitation, the exemplary architecture (100) may include a plurality of first users (102-1, 102-2…102-N) (collectively referred to as participants (102) or first users (102) and individually as a participant (102) or a first user (102)) associated with a plurality of user computing devices (104-1, 104-2…104-N) (also referred to as user devices (104) or computing devices (104) collectively and user device (104) individually), at least a network (106), at least a centralized server (112) and at least a second computing device (104) associated with an entity (108).
[0059] More specifically, the exemplary architecture (100) may include a system (110) equipped with an artificial intelligence (AI) engine (214). The user device (104) may be communicably coupled to the centralized server (112) through the network (106) to facilitate communication therewith. As an example, and not by way of limitation, the user computing device (104) may be operatively coupled to the centralized server (112) through the network (106) and may be associated with the entity (108).
[0060] In an embodiment, the user computing device (104) may communicate with the system (110) via a set of executable instructions residing on any operating system. In an embodiment, the user computing device (104) may include, but not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device. The computing device (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the user computing device (104) may not be restricted to the mentioned devices and various other devices may be used. A smart computing device may be one of the appropriate systems for storing data and other private/sensitive information.
[0061] In an exemplary embodiment, a network (106) may include, by way of example but not limitation, at least a portion of one or more networks (106) having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may include, by way of example but not limitation, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, some combination thereof.
[0062] In another exemplary embodiment, the centralized server (112) may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.
[0063] In an embodiment, the system (110) may include one or more processors coupled with a memory, wherein the memory may store instructions which when executed by the one or more processors may cause the system to manage network resources by MQTT encryption.
[0064] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
[0065] FIG. 2 with reference to FIG. 1, illustrates an exemplary block diagram (200) of the system (110), in accordance with an embodiment of the present disclosure.
[0066] In an aspect, the system (110) may comprise one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (206) of the system (110). The memory (206) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (206) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like.
[0067] In an embodiment, the system (110) may include an interface(s) (204). The interface(s) (204) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like. The interface(s) (204) may facilitate a communication of the system (110). The interface(s) (204) may also provide a communication pathway for one or more components of the system (110) or the centralized server (112). Examples of such components include, but are not limited to, processing engine(s) (208) and a database (210).
[0068] The processing engine(s) (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) (208) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (208). In such examples, the system (110) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (110) and the processing resource. In other examples, the processing engine(s) (208) may be implemented by electronic circuitry.
[0069] The processing engine (208) may include one or more engines selected from any of a data acquisition unit (212), an artificial intelligence (AI) engine (214), and other units (216).
[0070] The processing engine (208) may register the computing devices (104) with an embedded application to the network to get data from sensors of the computing devices (104).
[0071] The data acquisition unit (212) may determine whether the computing devices (104) with the embedded application is enabled based on the registration of the computing devices (104) to the network. Further, the data acquisition unit (212) may collect the application data corresponding to the embedded application from the sensors of the computing devices (104) in response to determining that the computing devices (104) with the embedded application is enabled.
[0072] The AI engine (214) may convert the application data corresponding to the embedded application into a predefined format. Also, the AI engine (214) may encrypt the application data corresponding to the embedded application via an encryption key based on the conversion of the application data.
[0073] The other units (216) may include, but not limited to, an optimization unit, a communication unit, and a decryption unit. The optimization unit may optimize network parameters to secure the encrypted application data. The network parameters include but not limited to a bandwidth, a payload, a Quality of service (QoS), a topic length, and a message size. The communication unit may establish TCP connection and MQTT connection with the server. The decryption unit may decrypt the encrypted application data via a decryption key by a subscriber associated with the computing device (104).
[0074] Although FIG. 2 shows exemplary block diagram (200) of the system (110), in other embodiments, the system (110) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (110) may perform functions described as being performed by one or more other components of the system (110).
[0075] FIG. 3 illustrates an exemplary representation (300) of a typical call flow with an embedded application having TLS implemented and seeking to send application data to a server.
[0076] Considering an example, a client initiates a secure communication session by starting a TLS Handshake. The client and the server then agree on the TLS version and the Cipher Suites for securing a channel. The whole process of securing application data over the TLS not just consumes network resources and time by adding significant overheads (calculation explained in the next section) but also effects the server performance due to CPU utilization as explained in FIG. 4. High security standard certificates are used by the server which degrades the server’s performance while handling multiple MQTT clients. For example, X509 server certificates with highest security standards (4096-bit certificates) is used which additionally affects performance in a negative way with additional overhead.
[0077] The TLS overhead may be calculated as: all intermediate issuer certificates in the certificate chain (minus the root cert). Since certificate sizes vary quite a bit based on the parameters and keys used, an average of 1500 bytes per certificate (self-signed certificates can be as small as 800 bytes) is used. The other varying factor is the length of the certificate chain up to the root certificate. To be on the more conservative side.
[0078] Referring to FIG. 3, Client Hello – the average size of initial client hello is about 160 to 170 bytes. It may vary based on the number of cipher suites sent by the client as well as how many TLS Client Hello extensions are present. If session resumption is used, another 32 bytes need to be added for the Session ID field.
[0079] Server Hello – this message is a bit more static than the Client Hello, but still variable size due to TLS extensions. The average size is 70 to 75 bytes.
[0080] Certificate – this message is the one that varies the most in size between different servers. The message carries the certificate of the server, as well as side of what is on the web, let’s assume 4 certificates in the chain. Overall this gives us about 6k for this message.
[0081] Client Key Exchange – Rivest–Shamir–Adleman (RSA) server certificate corresponds to size of 130 bytes for this message.
[0082] ChangeCipherSpec – fixed size of 1 (technically not a handshake message).
[0083] Finished – depending whether SSLv3 is used or TLS, the size varies quite a bit – 36 and 12 bytes respectively. Most implementations support TLSv1.0, so the TLS may be used and therefore the size will be 12 bytes.
[0084] The average size of each message exchanged may be used to calculate the average handshake size. The messages exchanged have TLS Record header for each record sent (5 bytes), as well as TLS Handshake header (4 bytes). The most common case can be simplified such that each arrow in the handshake diagram is a TLS Record, so 4 Records are exchanged for total of 20 bytes. Each message has the handshake header (except the ChangeCipherSpec one), so the Handshake header is 7 times for total of 28 bytes. The total overhead to establish a new TLS session comes to about 6.5k bytes on average (20 + 28 + 170 + 75 + 6000 + 130 + 2*1 + 2*12 = 6449).
[0085] Therefore, the process is very costly in terms of CPU utilization and bandwidth. Further, the TLS affects performance significantly, especially CPU usage during the handshake. Once MQTT clients are connected, the overhead is negligible.
[0086] FIG. 4 illustrates an exemplary representation (400) of CPU utilization for plain TCP vs. TLS. The whole process of securing application data over TLS not just consumes network resources and time by adding significant overheads but also effects the server performance due to CPU utilization. This process is very costly in terms of CPU utilization and bandwidth. TLS affects performance significantly, especially CPU usage during the handshake. Once MQTT clients are connected, the overhead is negligible.
[0087] FIG. 5 illustrates an exemplary flow mechanism (500) of MQTT payload encryption, in accordance with an embodiment of the present disclosure.
[0088] MQTT payload encryption is a good solution for sending application data if TLS may not be used. MQTT payload encryption may provide an additional layer of security since all the application data is secured. MQTT payload encryption may be used for constrained devices which may not use TLS. Since MQTT payloads are always binary, the need to encode the encrypted message to a textual representation such as base64 (the message is usually a raw byte array after encryption) may be avoided. MQTT payload encryption may save additional bandwidth. Text encodings may be typically more bloated than the raw byte representation. This approach ensures that the encrypted data stays encrypted all the time. While the MQTT broker uses the unencrypted packet metadata for routing and quality of service handling, the application data itself stays encrypted and the broker cannot read the encrypted data. Only trusted clients have access to a decryption key of the data.
[0089] If an attacker gets access to an MQTT packet (for example, due to improperly set up authentication and authorization or missing TLS), the attacker may not decrypt the data without the decryption key. There are two popular mechanisms for encrypting data, namely asymmetric encryption and symmetric encryption.
[0090] Asymmetric encryption requires two keys: One (public) key for encrypting (502) data and one (private) key for decrypting (504) data. Once data is encrypted with the public key, it is not possible to retrieve the original message with the public key. Only the private key may decrypt the data.
[0091] For MQTT payload encryption, asymmetric encryption is perfect for encrypting (502) the data, since there are only few trusted subscribers having access to the private key and many publishers that are possibly untrusted. The public key is not kept secret and everyone is allowed to encrypt (502) messages with that key. The important part is that only trusted clients can decrypt (504) the message again using the private key. Therefore, each MQTT topic gets its own public/private key pair.
[0092] Symmetric encryption: It is possible to encrypt and decrypt the message with the same key (which can be a password). Symmetric encryption is used in a trusted MQTT environment. Symmetric encryption tends to be easier to implement than asymmetric encryption and the provisioning process is also easier. Each MQTT topic may be assigned with its own key (password) using the symmetric encryption, so that if a password for the topic is lost, messages on other topics may not get decrypted by attackers. A rolling key and a session key may be included into the payload to prevent replay attacks making every message unique.
[0093] FIG. 6 illustrates an exemplary flow mechanism (600) of client to server call flow on MQTT with alternative security methods, in accordance with an embodiment of the present disclosure.
[0094] With respect to FIG. 6, at 602, a publisher for example the client may send a TCP synchronization request to a broker for example the server. On receiving the TCP synchronization request, the server sends a TCP synchronization acknowledgement response to the client. Further, the client synchronizes with the server. At 604, the client sends a MQTT connect command to the server. The server sends a MQTT connect acknowledgement response to the client on receiving the MQTT connect command. At 606, the client sends a MQTT subscription request to the server. On receiving the MQTT subscription request, the server sends a MQTT subscription acknowledgement response to the client. At 608, the client encrypts a MQTT publish payload using an encryption key and send the encrypted payload to the server. At 610, the server sends the encrypted payload to a subscriber. At 612, the subscriber decrypts the encrypted payload. Further, the client sends a MQTT disconnect request to the server after sending the encrypted payload, and disconnects the MQTT connection with the server.
[0095] Additional security methods may be used to secure MQTT on protocol level and malicious attacks. Additional security methods only forward expected traffic to downstream systems, and block any traffic that are not expected in downstream applications.
[0096] For an MQTT broker, the following traffic has to be blocked: Internet Control Message Protocol (ICMP): While it may not block all ICMP traffics, ICMP traffic, ping and traceroute ICMP packets may be investigated as candidates to block. MQTT defines a maximum message size of 256MB. In most MQTT deployment scenarios, messages are often smaller than a kilobyte. If the maximum message size is known, the maximum message size may be decreased to an allowed limit. If no limit is set, the malicious MQTT clients may send large messages (which may result in excessive memory consumption and unneeded bandwidth usage).
[0097] FIG. 7 illustrates an exemplary flow mechanism (700) of client to server MQTT call flow (without TLS and other security algorithm), in accordance with an embodiment of the present disclosure.
[0098] With respect to FIG. 7, the client sends the encrypted application data to the server by following steps:
[0099] At step 702, the client sends a TCP synchronization request to the server. On receiving the TCP synchronization request, the server sends a TCP synchronization acknowledgement response to the client. Further, the client synchronizes with the server. At 704, the client sends a MQTT connect command to the server. The server sends a MQTT connect acknowledgement response to the client on receiving the MQTT connect command. At 706, the client sends a MQTT subscription request to the server. On receiving the MQTT subscription request, the server sends a MQTT subscription acknowledgement response to the client. The client encrypts a MQTT publish payload using an encryption key and sends the encrypted payload to the server.
[00100] FIG. 8 illustrates an exemplary flow mechanism (800) of TLS handshake flow, in accordance with an embodiment of the present disclosure.
[00101] With respect to FIG. 8, MQTT requires reliable, lossless, and in-order delivery of packets, and thus, a TCP/IP-based protocol where a TCP connection needs to be established prior to transferring the data is required. MQTT is a three-phase handshake communication. First, a TCP connection has to be established as shown in 802. Second, the MQTT connection has to be established by exchange of keys as shown in 804. At 806, the data may be published using the keys. Finally, the TCP connection may be terminated after publishing the data as shown in 808.
[00102] FIG. 9 illustrates an exemplary flow diagram (900) of a process of saving network resources by MQTT method, in accordance with an embodiment of the present disclosure. With respect to FIG. 9, the network resources may be saved by following steps:
[00103] At 902, an IoT device (client) with an embedded application to get data from the sensors may be used. A cellular SIM card (NB-IoT) is inserted in the device that helps the device to register to a network. The MQTT method determines whether the device is enabled/turned ON or not.
[00104] At 904, on determining that the device is turned on, the embedded application performs the task of getting data from sensors of the device. The application data is then internally processed to convert into a predefined format that may be sent over a MQTT protocol. The data may be then encrypted by using one of the alternative encryption methods.
[00105] At 906, the device (client) may establish a TCP connection with the server.
[00106] At 908, the device (client) may establish an MQTT connection with the server.
[00107] At 910, the device (client) may publish the encrypted data to the server.
[00108] At 912, a subscriber may subscribe to the topic and consume the encrypted application data by decrypting the encrypted data.
[00109] At 914, the MQTT method may optimize the application data based on the topic length and saves the network resources.
[00110] At 916, the client disconnects the MQTT connection with the server, after sending the encrypted data to the server.
[00111] FIG. 10 illustrates an exemplary architecture (1000) for implementing the system (110), in accordance with an embodiment of the present disclosure.
[00112] With respect to FIG. 10, the system (110) includes a MQTT client device (1020) with an embedded application (1010), a MQTT broker (1030), a client subscription (1040), and a TCP/IP network (1050). The MQTT client device (1020) may be a publisher or a subscriber. The MQTT client device (1020) may establish a TCP/IP connection with the MQTT broker (1030) to transfer application data via the TCP/IP network (1050). The MQTT broker (1030) consumes the client subscription (1040) with different topics from the application data. The system (110) optimizes the application data with topic length to save network resources and reduce traffic overhead, processing time and resource utilization on a bandwidth constraint network.
[00113] FIG. 11 illustrates an exemplary block diagram of a computer system (1100) in which or with which embodiments of the present disclosure may be utilized.
[00114] As illustrated in the figure, the computer system (1100) may include an external storage device (1110), a bus (1120), a main memory (1130), a read only memory (1140), a mass storage device (1150), a communication port (1160), and a processor (1170). A person skilled in the art will appreciate that the computer system (1100) may include more than one processor (1170) and communication ports (1160). The processor (1170) may include various modules associated with embodiments of the present disclosure.
[00115] The communication port (1160) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (1160) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which computer system (1100) connects.
[00116] The memory (1130) may be a Random-Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (1140) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor (1170). The mass storage (1150) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions may include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage.
[00117] The bus (1120) communicatively couples the processor(s) (1170) with the other memory, storage and communication blocks. The bus (1120) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (1170) to the computer system (1100).
[00118] Optionally, operator and administrative interfaces, e.g., a display, keyboard, and a cursor control device, may also be coupled to the bus (1120) to support direct operator interaction with the computer system (1100). Other operator and administrative interfaces may be provided through network connections connected through the communication port (1160). The external storage device (1110) may be any kind of external hard-drives, floppy drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (1100) limit the scope of the present disclosure.
[00119] While the foregoing describes various embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof. The scope of the present disclosure is determined by the claims that follow. The present disclosure is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the present disclosure when combined with information and knowledge available to the person having ordinary skill in the art.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00120] The present disclosure provides a system that efficiently utilizes bandwidth of a cellular network, especially a Narrowband-Internet of Things (NB-IOT) network to make an IoT solution work flawlessly, without adding unnecessary load over the network.
[00121] The present disclosure secures application data over a Transport Layer Security (TLS) and reduces consumption of network resources and time in the whole process of securing application data over TLS.
[00122] The present disclosure reduces central processing unit (CPU) usage during handshake in a call flow with an embedded application having TLS implemented and seeking to send the application data to a server.

,CLAIMS:1. A system (110) for managing network resources by Message Queuing Telemetry Transport (MQTT) encryption, the system (110) comprising:
one or more processors (202); and
a memory (204) operatively coupled to the one or more processors (202), wherein the memory (204) comprises processor-executable instructions, which on execution, cause the one or more processors (202) to:
register one or more computing devices (104) with an embedded application to a network (106);
encrypt application data corresponding to the embedded application based on registration of the one or more computing devices (104);
optimize at least one network parameter of a plurality of network parameters to secure the encrypted application data; and
send the secured application data to a server (112) by establishing an MQTT connection with the server (112) in response to optimization of the at least one network parameter of the plurality of network parameters.

2. The system (110) as claimed in claim 1, wherein the one or more processors (202) are to encrypt the application data corresponding to the embedded application by being configured to:
determine whether the one or more computing devices (104) with the embedded application are enabled based on the registration of the one or more computing devices (104) to the network (106);
collect the application data corresponding to the embedded application from one or more sensors of the one or more computing devices (104) in response to a determination that the one or more computing devices (104) with the embedded application are enabled;
convert the application data corresponding to the embedded application into a predefined format; and
encrypt the application data corresponding to the embedded application via an encryption key based on the conversion of the application data.

3. The system (110) as claimed in claim 1, wherein the one or more processors (202) are to establish the MQTT connection with the server (112) by being configured to:
send an MQTT Connect Command to the server (112);
receive an MQTT Connect Accept response from the server (112);
establish a Transmission Control Protocol (TCP) connection with the server (112) in response to receiving the MQTT Connect Accept response from the server (112); and
establish the MQTT connection with the server (112) in response to establishing the TCP connection with the server (112).

4. The system (110) as claimed in claim 1, wherein the memory (204) comprises processor-executable instructions, which on execution, cause the one or more processors (202) to:
send an application data subscription request to the server (112);
receive an application data subscription accept response from the server (112); and
send the encrypted application data to at least one subscriber associated with at least one computing device (104) in response to receiving the application data subscription accept response from the server (112).

5. The system (110) as claimed in claim 4, wherein the secured application data is decrypted via a decryption key by the at least one subscriber associated with the at least one computing device (104).

6. The system (110) as claimed in claim 1, wherein the at least one network parameter of the plurality of network parameters comprise at least one of: a bandwidth, a payload, a Quality of service (QoS), a topic length, and a message size.

7. A method for managing network resources by Message Queuing Telemetry Transport (MQTT) encryption, the method comprising:
registering, by a processor (202) associated with a system (110), one or more computing devices (104) with an embedded application to a network (106);
encrypting, by the processor (202), application data corresponding to the embedded application based on registration of the one or more computing devices (104);
optimizing, by the processor (202), at least one network parameter of a plurality of network parameters to secure the encrypted application data; and
sending, by the processor (202), the secured application data to a server (112) by establishing an MQTT connection with the server (112).

8. The method as claimed in claim 7, wherein encrypting, by the processor (202), the application data corresponding to the embedded application comprises:
determining, by the processor (202), whether the one or more computing devices (104) with the embedded application are enabled based on the registration of the one or more computing devices (104) to the network (106);
collecting, by the processor (202), the application data corresponding to the embedded application from one or more sensors of the one or more computing devices (104) in response to determining that the one or more computing devices (104) with the embedded application are enabled;
converting, by the processor (202), the application data corresponding to the embedded application into a predefined format; and
encrypting, by the processor (202), the application data corresponding to the embedded application via an encryption key based on conversion of the application data.

9. The method as claimed in claim 7, wherein establishing, by the processor (202), the MQTT connection with the server (112) comprises:
sending, by the processor (202), an MQTT Connect Command to the server (112);
receiving, by the processor (202), an MQTT Connect Accept response from the server (112);
establishing, by the processor (202), a Transmission Control Protocol (TCP) connection with the server (112) in response to receiving the MQTT Connect Accept response from the server (112); and
establishing, by the processor (202), the MQTT connection with the server (112) in response to establishing the TCP connection with the server (112).

10. The method as claimed in claim 7, comprising:
sending, by the processor (202), an application data subscription request to the server (112);
receiving, by the processor (202), an application data subscription accept response from the server (112); and
sending, by the processor (202), the encrypted application data to at least one subscriber associated with at least one computing device (104) in response to receiving the application data subscription accept response from the server (112).

11. The method as claimed in claim 10, wherein the encrypted application data is decrypted via a decryption key by the at least one subscriber associated with the at least one computing device (104).

12. The method as claimed in claim 8, wherein the at least one network parameter of the plurality of network parameters comprise at least one of: a bandwidth, a payload, a Quality of service (QoS), a topic length, and a message size.

13. A user equipment, comprising:
one or more processors; and
a memory operatively coupled to the one or more processors, wherein the memory comprises processor-executable instructions, which on execution, cause the one or more processors to:
encrypt application data corresponding to an embedded application of one or more computing devices (104) based on registration of the one or more computing devices (104);
optimize at least one network parameter of a plurality of network parameters to secure the encrypted application data at a server (112); and
send the secured application data to the server (112) by establishing a Message Queuing Telemetry Transport (MQTT) connection with the server (112).

Documents

Application Documents

# Name Date
1 202221040671-STATEMENT OF UNDERTAKING (FORM 3) [15-07-2022(online)].pdf 2022-07-15
2 202221040671-PROVISIONAL SPECIFICATION [15-07-2022(online)].pdf 2022-07-15
3 202221040671-POWER OF AUTHORITY [15-07-2022(online)].pdf 2022-07-15
4 202221040671-FORM 1 [15-07-2022(online)].pdf 2022-07-15
5 202221040671-DRAWINGS [15-07-2022(online)].pdf 2022-07-15
6 202221040671-DECLARATION OF INVENTORSHIP (FORM 5) [15-07-2022(online)].pdf 2022-07-15
7 202221040671-ENDORSEMENT BY INVENTORS [14-07-2023(online)].pdf 2023-07-14
8 202221040671-DRAWING [14-07-2023(online)].pdf 2023-07-14
9 202221040671-CORRESPONDENCE-OTHERS [14-07-2023(online)].pdf 2023-07-14
10 202221040671-COMPLETE SPECIFICATION [14-07-2023(online)].pdf 2023-07-14
11 202221040671-FORM-8 [24-07-2023(online)].pdf 2023-07-24
12 202221040671-FORM 18 [24-07-2023(online)].pdf 2023-07-24
13 Abstract1.jpg 2023-12-20
14 202221040671-FER.pdf 2025-08-28

Search Strategy

1 202221040671_SearchStrategyNew_E_202221040671E_27-08-2025.pdf