Technical Field
[001] The present disclosure relates generally to Internet of Things (loT), and more particularly to system and method for facilitating designing of an loT infrastructure for deploying an loT application.
Background
[002] Internet of Things (loT) is an interconnection of computing devices embedded in everyday objects or things, thereby enabling them to send and receive data and, therefore, allowing them to interact in a physical world. For example, in case of proximity detection, two loT devices may be employed that may interact with each other. One of the two loT device may emit an audio along with a data packet, and another loT device may detects the audio and the data packet. Based on a correlation between the detected audio and the data packet a distance between the two loT devices may be calculated. To design an loT infrastructure a large number of loT components may be required to be evaluated and/or processed. The plurality of loT components may include physical devices, sensors, data extraction techniques, secured communication techniques, loT gateways, cloud servers, analytics and dashboards.
[003] Various systems are available to provide assistance while designing the loT infrastructure. Typically, existing techniques allow for passive and manual selection of loT components while designing the loT infrastructure. However, such manual activity consumes a lot of time. Further, a wide array of loT components are available in the market and understanding of all these loT components are impossible which leads to delay and incorrect processing of the loT components. It is therefore desirable to address the aforementioned issues and to provide an improved and efficient technique and for designing an loT Infrastructure for deployment of an loT application

[004] In one embodiment, a method of facilitating designing of an Internet of Things (loT) infrastructure for deploying an loT application is disclosed. In one example, the method may include determining a Manhattan distance between each of a plurality of existing requirements and a new requirement. The new requirement may be with respect to the loT infrastructure for deploying the loT application. The method may further include identifying one or more of the plurality of existing requirements corresponding to a minimum Manhattan distance. The method may further include determining a relevancy score for each of the one or more identified existing requirements based on a similarity between the each of the one or more identified existing requirements and the new requirement. The method may further include providing one or more loT components and one or more loT designs corresponding to a similar existing requirement for facilitating designing of the loT infrastructure. The similar existing requirement may include one of the one or more identified existing requirement with a maximum relevancy score.
[005] In another embodiment, a system for facilitating designing of an loT infrastructure for deploying an loT application is disclosed. In one example, the system may include a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may causes the processor to determine a Manhattan distance between each of a plurality of existing requirements and a new requirement. The new requirement may be with respect to the loT infrastructure for deploying the loT application The processor-executable instructions, on execution, may further cause the processor to identify one or more of the plurality of existing requirements corresponding to a minimum Manhattan distance. The processor-executable instructions, on execution, may further cause the processor to determine a relevancy score for each of the one or more identified existing requirements based on a similarity between the each of the one or more identified existing requirements and the new requirement. The processor-executable instructions, on execution, may further cause the processor to provide one or more loT components and one or more loT designs corresponding to a similar existing requirement for facilitating designing of the loT infrastructure. The similar existing requirement may

include one of the one or more identified existing requirement with a maximum relevancy score.
[006] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[007] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[008] FIG. 1 is a functional block diagram of an exemplary system for facilitating designing of an Internet of Things (loT) infrastructure for deploying an loT application, in accordance with some embodiments of the present disclosure.
[009] FIG. 2 is a flow diagram of an exemplary process for facilitating designing of an loT infrastructure for deploying an loT application, in accordance with some embodiments of the present disclosure.
[010] FIG. 3 is a flow diagram of a detailed exemplary process for facilitating designing of an loT infrastructure for deploying an loT application, in accordance with some embodiments of the present disclosure.
[011] FIG. 4 is a schematic diagram of an exemplary system for facilitating designing of an loT infrastructure for a new requirement, in accordance with some embodiments of the present disclosure.
[012] FIG. 5 is a table representing a plurality existing requirements and corresponding plurality of loT design components, in accordance with some embodiments of the present disclosure.
[013] FIG. 6 is a table representing Manhattan distances corresponding to a plurality of existing requirements with respect to a new requirement, in accordance with some embodiments of the present disclosure.
[014] FIG 7 is a table representing tokenized existing requirements with minimum Manhattan distance, in accordance with some embodiments of the present disclosure.

[015] FIG. 8 is a table representing binary vectors corresponding to tokenized existing requirements, in accordance with some embodiments of the present disclosure.
DETAILED DESCRIPTION
[016] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims. Additional illustrative embodiments are listed below.
[017] Referring now to FIG. 1, a functional block diagram of an exemplary system 100 for facilitating designing of an Internet of Things (loT) infrastructure is illustrated, in accordance with some embodiments of the present disclosure. The loT infrastructure need to be designed for deploying an loT application. The system 100 includes an input module 101, a processing module 102, a database 103, and an output module 104. As will be discussed in greater detail below, in some embodiments, the one or more modules 101 - 104 may be hosted on a processing device. The processing module 102 may include a prediction module 105 and an updating module106. The prediction module 105 and the updating modulel 06 may further include various modules to perform different operations so as to facilitate designing of the loT infrastructure. In particular, the prediction module 105 includes an loT design selection module 107 and an loT component selection module 108. In some embodiments, the database 103 may be a blockchain distribution ledger 111. In such embodiments, the updating module 106 may include a block creation module 109 and a block validation module 110.
[018] The input module 101 may fetch a plurality of user requirements through a user device. It should be noted that a user requirement may correspond to a new requirement. The plurality of user requirements may include one or more tasks to be performed, an amount of dataflow required, and a load handling capacity required. In some embodiments, the user device may be a phone, a computer, a laptop device, or

the like. Further, the input module 101 may transmit the plurality of user requirements to the connected processing module 102.
[019] As stated above, the processing module 102 may be hosted on the processing device. For example, the processing device may be a server. In some embodiments, the processing module 102 may be hosted on a local server. In some other embodiments, the processing module 102 may be hosted on a remote server. A connectivity between the input module 101 and the processing module 102 may be established via at least one of a Wi-Fi, a Bluetooth connection, mobile data, or the like.
[020] The prediction module 105 of the processing module 102 may be configured to receive the plurality of user requirements from the input module 101. The prediction module 105 may be connected to the database 104. In some embodiments, the database 104 may include the blockchain distributed ledger 111. As will be appreciated, the blockchain distributed ledger 111 may be managed over a peer to peer network, where a plurality of computer devices may be connected to each other via internet connection. The prediction module 105 is configured to store and/or retrieve a plurality of historical loT design components as well as a plurality of historical loT designs in and/or from the database 103 (e.g., blockchain distributed ledger 111). In some embodiments, the plurality of historical loT design components may include a plurality of device components, a plurality of gateway components, a plurality of cloud platform components, and a plurality of analytic components.
[021] Further, the plurality of device components may include sensors, actuators, detectors, or the like. The plurality of gateway components may include raspberry pi, Eurotech, ad link, dell edge, or the like. The plurality of cloud components may include amazon web services, Microsoft azure and the like. Examples of the plurality of analytic components may be a tableau, power bi and the like.
[022] In some embodiments, the blockchain distributed ledger 111 may also store a cryptographic wallet, that includes a plurality of encryption protocols. The cryptographic wallet may be stored in order to securely store the plurality of loT design components. It should be noted that the cryptographic wallet enables the users to access the peer-to-peer network on which the blockchain distributed ledger 111 is being managed.

[023] The loT design selection module 107 of the prediction module 105 may be configured to compute a Manhattan distance. The Manhattan distance may be computed between each of a plurality of existing requirements and the new requirement. In some embodiments, the plurality of existing requirements and the new requirement may be tokenized so as to determine relevancy between each of the plurality of existing requirements and the new requirement. The loT design selection module 107 may be configured to select one or more tokenized existing requirements with minimum Manhattan distance with respect to the new requirement. The loT design selection module 107 may convert all the selected tokenized existing requirements (i.e., tokenized existing requirements with minimum Manhattan distance) and the tokenized new requirement into corresponding binary vectors. It should be noted that for each token may be assigned a binary value (i.e., '0' or '1') to form binary vectors. The conversion may be done to identify an appropriate loT design structure.
[024] The loT design selection module 107 may further calculate relevancy scores for identified existing requirements based on the converted binary vectors. In some embodiments, the loT design selection module 107 may calculate the relevancy score of an identified existing requirement based on a cosine similarity between the identified existing requirement and the new requirement. Thereafter, based on the calculated relevancy scores, an loT design may be selected for the new requirement. In particular, the selected loT design may correspond to a similar existing requirement. In some embodiments, the similar existing requirement may be one or more identified existing requirement with maximum relevancy score
[025] The loT component selection module 108 may select at least one gateway component from a plurality of gateway components based on historical data. The historical data may include the plurality of gateway components that may be employed in past for designing various loT infrastructures based on at least a corresponding selected device component. It should be noted that, the gateway component may be a component that offer a certain level of security for the network and transmitted data with higher order encryption techniques. The gateway component may act as a middle layer between the device component and a cloud component to protect the system 100 from malicious attacks and unauthorized access.

[026] Also, the loT component selection module 108 may select at least one cloud component from a plurality of cloud components based historical data. In some embodiments, the historical data may include the plurality of cloud components used in the past for designing the plurality of loT infrastructures based on at least one corresponding selected gateway component. It may be noted that the cloud component is a component that integrates plurality of devices, sensors, gateways, protocols, data storages, and provides predictive analytics.
[027] Further, the loT component selection module 108 may be configured to select at least one analytic component from the plurality of analytic components based on historical data. In some embodiments, the historic data may include the plurality of analytic components used in the past for designing the plurality of loT infrastructures based on at least one corresponding selected cloud component. The analytic component may be a process of converting analog data from plurality of smart devices and sensors into useful insights. That may be further interpreted and used for detailed analysis.
[028] The updating module 106 may be operatively coupled to the prediction module 105. The updating module 106 may be configured to update the database 103 (e.g., blockchain distributed ledger 111) by storing the design of loT infrastructure corresponding to the new requirement in the database 103 (e.g., blockchain distributed ledger 111). Further, in the embodiments where the database 103 is blockchain distributed ledger 111, the block creation module 109 of the updating module 106 may be configured to create a block for updating the blockchain distributed ledger 111. Additionally, the block creation module 109 may be configured to transmit the created block to a plurality of nodes over the peer-to-peer network. The block validation module
110 of the updating module 106 may enable the plurality of nodes to validate the created
block by performing a proof of work. In the current context, the proof of work may be
where miners may compete against each other to complete transactions on the network.
The block validation module 110 may reward one or more of the plurality of nodes, based
on performance of each of the plurality of nodes.
[029] The updating module 106 may update the blockchain distributed ledger
111 by appending the created block to the blockchain distributed ledger 111, upon

receiving a reward for the proof of work. In one embodiment, the updating module 106 may be configured to append created block to the blockchain distributed ledger 111 by utilizing a one-way hashing technique. In some embodiment, the updating module 106 may enable a plurality of users to update one or more loT designs or loT components in the blockchain distributed ledger 111. It should be noted that the plurality of users may access the blockchain distributed ledger 111 by using cryptographic wallets. The processing module 102 may be further communicatively connected to the output module 104.
[030] The output module 104 may receive the identified loT design and loT components from the processing module 102. The output module 104 is configured to provide the identified loT design and loT components to the user through the user device. The identified loT design and loT components may facilitate designing of the loT infrastructure with respect to the new requirement.
[031 ] It should be noted that the processing module 102 may be implemented in programmable hardware devices such as programmable gate arrays, programmable array logic, programmable logic devices, or the like. Alternatively, the processing module 102 may be implemented in software for execution by various types of processors. An identified engine/module of executable code may, for instance, include one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, module, procedure, function, or other construct. Nevertheless, the executables of an identified engine/module need not be physically located together but may include disparate instructions stored in different locations which, when joined logically together, comprise the identified engine/module and achieve the stated purpose of the identified engine/module. Indeed, an engine or a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[032] In some embodiments, some part of system 100 may be easily deployed in any cloud-based servers for access and use as an 'application as a service'. For example, the processing module 102 may be implemented on a cloud-based server and used for facilitating designing of an loT infrastructure for deploying an loT application.

[033] As will be appreciated by one skilled in the art, a variety of processes may be employed for facilitating designing of an loT infrastructure for deploying an loT application. For example, the exemplary system 100 may facilitate designing of an loT infrastructure for deploying an loT application, by the process discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some or all the processes described herein may be included in the one or more processors on the system 100.
[034] Referring now to FIG. 2, an exemplary process 200 for facilitating designing of an loT infrastructure for deploying an loT application is depicted via a flow chart, in accordance with some embodiments of the present disclosure. Each step of the process 200 may be performed by the processing module 102.
[035] As illustrated in the process 200, at step 201, a Manhattan distance between each of a plurality of existing requirements and a new requirement may be determined. It should be noted that the new requirement may be with respect to the loT infrastructure for deploying the loT application. In some embodiments, the new requirement may be received from a user or a system. Additionally, in some embodiments, the new requirement may include at least one of a task to be performed, an amount of dataflow required, and a load handling capacity required. Further, in some embodiments, the plurality of existing requirements may be retrieved from a database. It should be noted that, in some embodiments, the database may be a blockchain distributed ledger. Further, in some embodiments, each of the plurality of existing requirement may be retrieved along with one or more corresponding loT components and one or more corresponding loT designs. Moreover, in some embodiments, the plurality of existing requirements may correspond to the new requirement.
[036] In some embodiments, each of the plurality of existing requirements and the new requirement may be tokenized into a corresponding set of tokens. Additionally,

in some embodiments, a difference may be computed between the corresponding set of tokens for each of the plurality of existing requirements and the corresponding set of tokens for the new requirement. The Manhattan distance is then determined based on the computed difference.
[037] At step 202, one or more of the plurality of existing requirements may be identified corresponding to a minimum Manhattan distance. At step 203, a relevancy score may be determined for each of the one or more identified existing requirements. The relevancy score may be determined based on a similarity between the each of the one or more identified existing requirements and the new requirement. In some embodiments, each of the one or more identified existing requirements and the new requirement may be converted into respective binary vectors. It should be noted that a total number of attributes in the binary vector may correspond to a total number of tokens in a union of the two or more corresponding set of tokens. Additionally, it should be noted that an attribute of T in a binary vector may correspond to a presence of a corresponding token, while an attribute of '0' in the binary vector corresponds to an absence of the corresponding token. Further, in some embodiments, the relevancy score for the each of the one or more identified existing requirements with respect to the new requirement may be determined based on a cosine similarity between the respective binary vectors.
[038] At step 204, one or more loT components and one or more loT designs corresponding to a similar existing requirement may be provided to the user or the system for facilitating designing of the loT infrastructure. It should be noted that the similar existing requirement may include one or more identified existing requirement with a maximum relevancy score. In some embodiments, the database may be updated by storing the new requirement, the one or more loT components, and the one or more loT designs for subsequent use. As stated above the database may be a blockchain distributed ledger.
[039] Referring now to FIG. 3, an exemplary process 300 for facilitating designing of an loT infrastructure for deploying an loT application is depicted via a flow chart in greater detail, in accordance with some embodiments of the present disclosure. Each step of the process 300 may be performed by various modules 105-110 of the

processing module 102. Initially, at step 301, a new requirement from a user may be fetched via a user device by the input module 101. It should be noted that fetching the new requirement may include fetching one or more tasks to be performed, amount of dataflow required in the loT infrastructure, load handling capacity requirement. In some embodiments, the new requirement may be fetched from the user via a phone, a computer device, a laptop, and the like.
[040] At step 302, existing requirements, a plurality of loT components, and a plurality of loT designs may be stored in the blockchain distributed ledger 111. In some embodiment, storing the plurality of loT components may include storing a plurality of device components, a plurality of gateway components, a plurality of cloud components and a plurality of analytic components. Further, a plurality of encryption protocols present in a cryptographic wallet may be used to store the existing requirements, the plurality of loT components, and the plurality of loT designs. By employing the encryption protocols, security of the system may be enhanced.
[041] At step 303, a Manhattan distance between each existing requirement corresponding to the new requirement may be computed. The Manhattan distance may be sum of absolute difference between data points across all dimensions of an existing requirement and the new requirement. Initially, both the existing requirement and the new requirement may be converted into numeric values. The Manhattan distance may be then calculated, as per equation (1) given below:
Manhattan Distance = |pi-qi|+|p2-q2|+ +|pn-qn| Equation (1)
where, 'n' represents number of dimensions (e.g., number of tokens), 'p' denotes a data point (e.g., token) corresponding to the existing requirement, and 'q' denotes a data point (e.g., token) corresponding to the new requirement. It should be noted that the Manhattan distance may be preferable distance metrics due to involvement of high dimensional data as a part of the requirements. In other words, there may be 'N' number of texts corresponding to a requirement. Further, when the requirement is converted to numeric data, it may result in more dimensions. Thus, the Manhattan distance calculation is most suitable to find a difference between two high dimensional data. Further, the Manhattan distance may be preferable as it uses absolute value distance that give more robust results. However, it should be noted that, in some embodiments, other distance metrics

(e.g., Euclidean distance) may be employed in place of the Manhattan distance to achieve similar objective and to get similar results.
[042] For example, the existing requirement is tokenized that includes tokens 'loT infrastructure', 'Air Pollution', 'monitoring', and 'detection'. On the other hand, tokens generated for the new requirement may include 'loT infrastructure', 'Gas leakage' 'monitoring' and 'detection'. Now, to calculate the Manhattan distance each token is converted into a numerical value. Both the existing and new requirements include loT infrastructure, monitoring, and detection so the numerical value corresponding to each of these tokens may be T. For 'Air Pollution', the numerical value in case of existing requirement may be T, and '0' in case of the new requirement, as the token 'Air Pollution' is only present in the existing requirement. In a similar way, the new requirement, for the token 'Gas leakage', is assigned with a value T. And, in case of the existing requirement the numerical value is '0', for the token 'Gas detection'.
[043] Consequently, the data points for the existing requirement are pi=1, p2=1, P3=1, p4=1, and p5=0. The new requirement includes the data points qi=1, q2=0, q3=1, q4=1, and qs=1. Now, as per the given equation (1), the Manhattan distance may be calculated as:
Manhattan Distance = |1-1|+|1-0||+|1-1||+|1-1||+|0-11 = 0+1+0+0+1 =2
[044] At step 304, the tokenized requirements with minimum difference of the Manhattan distance may be selected. By comparing Manhattan distances of all the tokenized requirements, a minimum Manhattan distance value may be identified. And, one or more of the tokenized requirements having the minimum Manhattan distance value may be selected for further processing. Consider an example that includes five tokenized requirements for example Ri, R2, R3, R4, and R5. The Manhattan distances for the five tokenized requirements may be calculated by using the equation (1) and that may result in the Manhattan distances Mi=2, M2=4, M3=2, M4=3, and Ms=4. Now, the minimum Manhattan distance is M2=2 that is associated with the tokenized requirements R1, and R3. Hence, the prediction module 105 for this example may select the tokenized requirements Ri.and R3from tokenized requirements R1, R2, R3, R4, and R5.
[045] At step 305, tokenized requirements with minimum difference of the Manhattan distance (for example R1 and R3 selected in the previous step) and the new

requirement may be converted into respective binary vectors. An attribute T in the binary vector may correspond to a presence of a corresponding token. Further, an attribute '0' may correspond to an absence of a corresponding token in the binary vector. It should be noted that a total number of attributes in the binary vector may correspond to a total number of tokens in a union of the one or more corresponding set of tokens.
[046] At step 306, a relevancy score based on the converted minimum difference of the Manhattan distance and the converted new requirement may be calculated. Further, the relevancy score may be calculated based on a cosine similarity between each of the binary vectors of the existing requirement and the binary vector of new requirement. The cosine similarity between two vectors may be calculated, as per equation (2) given below:
where, A is the existing requirement and B is the new requirement. It should be noted that the smaller the angel between two vectors, the higher the cosine similarity. Further, it should be noted that the Cosine similarity may be preferable over other similarity metrics because even if the two requirements seems to be very different by other similarity metrics (e.g., Euclidian distance), there are probabilities that they may be still similar. For example, frequent words in the requirements may have higher Euclidian distance than the less frequent words. However, this is not the same with Cosine similarity. Thus, when the similarity has to be calculated for two semantically similar words but with different frequency, then Cosine similarity may be preferred over Euclidian distance.
[047] At step 307, a desired loT infrastructure may be designed based on the relevancy score. For designing the desired loT infrastructure, the plurality of loT design components and the plurality of loT designs may be selected, corresponding to the new requirement.
[048] Thereafter, at step 308, the blockchain distributed ledger 111 may be updated by storing the identified design of loT infrastructure in the blockchain distributed ledger 111. It should be noted that the updating module 106 may update the blockchain distributed ledger 111. In some embodiments, a block for updating the blockchain

distributed ledger 111 may be created by the block creation module 109. The created block may be then sent to a plurality of nodes over the peer to peer network. Additionally, in some embodiments, the plurality of nodes may be enabled to validate the created block by performing a proof of work. Enabling of the nodes may performed by the block validation module 110. Thereafter, based on performance of the plurality of nodes, one or more of the plurality of nodes may be rewarded. After receiving the rewards from the proof of work, the blockchain distributed ledger 111 may be updated. In some embodiments, the created block may be appended to the blockchain distributed ledger 111 for updating the blockchain distributed ledger 111. It should be noted that a one¬way hashing technique may be used to append the created block.
[049] At step 309, the identified design of loT infrastructure may be provided to the user. The output module 104 may render the identified design of loT infrastructure to the user via the user device.
[050] By way of an example, referring now to FIGS. 4 - 8, a system 400 (analogous to the system 100) for designing the loT infrastructure for a new requirement is illustrated, in accordance with some embodiments of the present disclosure. In the illustrated example, the new requirement may be designing of the loT infrastructure for deploying an loT application for gas leakage detection and monitoring. The system 400 includes a user 401, a user device 402, an input module 403 (analogous to the input module 101), a processing module 404 (analogous to the processing module 102), a blockchain distributed ledger 405 (analogous to the blockchain distributed ledger 111), and an output module 406 (analogous to the input module 104). The input module 403, the processing module 404 and the output module 406 may be hosted on a processing device 407. The user 401 may provide the new requirement to the input module 403 through the user device 402. It should be noted that the user device may be a laptop, a computer, a microcontroller, a tablet, a mobile or the like.
[051] Thereafter, the new requirement may be passed through the processing module 404. In some embodiments, the user 401 may provide detailed information about the new requirement in order to design the corresponding loT infrastructure. The detailed information about the new requirement may include amount of dataflow required by the user with respect to the loT infrastructure being designed (e.g., for validating gas

leakage detection and monitoring). After receiving the detailed information from the input module 403, the processing module 404 may access the historical data in the blockchain distributed ledger 405. The blockchain distributed ledger 405 includes a plurality of loT designs, and a plurality of loT components used in past. Thereafter, checks whether the loT design for validating gas leakage detection and monitoring is already available in the blockchain distributed ledger 405 or not. In some embodiments, when the loT design is available, the processing module 404 may provide the required loT design to the user 401.
[052] In case, the loT design for validating gas leakage detection and monitoring is not available, the processing module 404 may check the plurality of loT design components in the historical data to identify similar requirements, in accordance with some embodiments of the present disclosure. For example, in some embodiments, for designing loT infrastructure, the processing module 404 may select the loT design components that validates the gas leakage detection in the blockchain distributed ledger 405. Based on the selection, the processing module 404 may identify the most relevant loT design or loT components that may be further provided to the user 401, via the user device 402. For identifying the most relevant loT design or loT components various steps like calculating Manhattan distance, and determining relevancy scores may be performed. These steps are already explained in conjunction to FIGS. 1-3 and will be explained for the aforementioned example of gas detection and monitoring in conjunction with FIGS. 5-8.
[053] Referring now to FIG. 5, a table 500 representing a plurality of existing requirements 501 and corresponding plurality of loT design components 502 - 506 is illustrated, in accordance with some embodiments of the present disclosure. For example, a first column 501 of the table 500 represents the existing requirements. And, remaining columns 502 - 506 of the table 500 represents the corresponding loT design components for the existing requirements. In the illustrated embodiment, the loT design components may include a device 502, connectivity 503, gateway 504, cloud 505, and analytics 506. It should be noted that the aforementioned loT design components are only exemplary and there may be many more design components mapped to each of the existing requirements. In the illustrated embodiment, the first existing requirement is

an "loT infrastructure for air pollution detection, monitoring and alert" and corresponding loT design components are 'Sensor V device, Bluetooth connectivity, Rasperry PI gateway, AWS cloud, and AWS loT analytics.
[054] Referring now to FIG. 6, a table representing Manhattan distances 603 corresponding to a plurality of existing requirements 601 is illustrated, in accordance with some embodiments of the present disclosure. When the processing module 404 receives a new requirement, for example 'loT infrastructure for gas leakage detection and monitoring, the Manhattan distance between all the existing requirements (shown in table 500) corresponding to the new requirement may be calculated. It should be noted that initially tokens for each of the existing requirements of the table 500 may be generated that may be represented by tokenized loT requirements 601 in the table 600. By the way of an example, for the first existing requirements have tokens as Air, Pollution, Detection, Monitoring, and Alert. Similarly, for other existing requirements tokens are different as shown in Fig. 6. In the illustrated embodiment, the Manhattan distance 603 calculated for the first tokenized requirement with respect to the new requirement may be '2'. It should be noted that the Manhattan distances may be calculated using the equation (1).
[055] Referring now to FIG. 7, a table 700 representing tokenized requirements with minimum Manhattan distance, in accordance with some embodiments of the present disclosure is illustrated. From the table 700, it is clear that total three tokenized existing requirements 701 are selected out of ten tokenized requirements. These four tokenized existing requirements 701 may be selected by the processing module 404 based on the minimum Manhattan distance. It is clearly seen in the table 600 that the minimum Manhattan distance 2 out of three different Manhattan distances 2, 3, and 4. The tokenized requirements associated with the minimum Manhattan distance 2 are first, fifth, and eighth tokenized requirements. Also, the new requirement 702 with tokens and device component may also be included in a last row of the table 700
[056] Referring now to FIG. 8, a table 800 representing binary vectors corresponding to each tokenized requirement is illustrated, in accordance with some embodiments of the present disclosure. Existing requirements 801 may include REQ1, REQ2, and REQ3. For each of the existing requirements 801 and the new requirement

802 a binary vector may be calculated. To calculate a binary vector, each token is considered. An attribute T for the presence of a corresponding token. Further, '0' is for an absence of the corresponding token, as shown in the table 800. Based on the table 800 the processing device may calculate relevancy scores.
[057] For example, in the table 800, REQ4 may be mapped with REQ1, REQ2 and REQ3 to find out the relevancy scores. Firstly, for cosine similarity the equation (2) may be referred, and in the equation 'A' is the REQ1 and 'B' is the REQ4. Then, a relevancy score of cosine similarity may be [REQ1: REQ4] Cosine Similarity = 3/ (SQRT (6) * SQRT (5)) = 0.548. Similarly, when REQ2 and REQ3 are mapped with REQ4, the obtained relevancy scores may be 0.89 and 0.6708, respectively. It is clearly seen that the relevancy score of REQ2 is maximum corresponding to the new requirement REQ4. Hence, the REQ2 may be selected for designing the new requirement of gas detection and monitoring.
[058] The present disclosure may provide many advantages in order to overcome the problems encountered in conventional systems and methods. As discussed above, the present disclosure uses cryptographic wallets that may enable the users to access blockchain technology-based database, peer-to-peer network, securely, to facilitate loT component processing. As the blockchain technology is used, the historical data may be maintained automatically in the database with regular updates, which reduces manual efforts. Additionally, the systems and methods described in the present disclosure may provide accurate analysis that may help various organizations to predict trends in the market and to plan a successful implementation. Performance issues existing in the conventional systems and methods may also be overcome by the present disclosure, effectively by providing high loT response time. Moreover, the disclosure provides, a real time smart analytics that may help engineers to find out irregularities in collected data and act fast to prevent an undesired scenario, and a predictable level of service with improved ownership and accountability.
[059] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units

and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[060] The specification has described method and system for facilitating designing of an loT infrastructure for deploying an loT application. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[061] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.

[062] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.

WHAT IS CLAIMED IS:
1. A method (200) of facilitating designing of an Internet of Things (loT) infrastructure
for deploying an loT application, the method (200) comprising:
determining (201), by a processing device (407), a Manhattan distance between each of a plurality of existing requirements and a new requirement, wherein the new requirement is with respect to the loT infrastructure for deploying the loT application;
identifying (202), by the processing device (407), one or more of the plurality of existing requirements corresponding to a minimum Manhattan distance;
determining (203), by the processing device (407), a relevancy score for each of the one or more identified existing requirements based on a similarity between the each of the one or more identified existing requirements and the new requirement; and
providing (204), by the processing device (407), one or more loT components and one or more loT designs corresponding to a similar existing requirement for facilitating designing of the loT infrastructure, wherein the similar existing requirement comprises one or more identified existing requirement with a maximum relevancy score.
2. The method (200) of claim 1, further comprising:
receiving the new requirement from a user or a system, wherein the new requirement comprises at least one of a task to be performed, an amount of dataflow required, and a load handling capacity required; and
retrieving the plurality of existing requirements from a database (103), wherein the database (103) comprises a blockchain distributed ledger (111), wherein each of the plurality of existing requirement is retrieved along with one or more corresponding loT components and one or more corresponding loT designs, and wherein the plurality of existing requirements correspond to the new requirement.
3. The method (200) of claim 2, further comprising updating the database (103) by
storing the new requirement, the one or more loT components, and the one or more loT
designs for subsequent use.

4. The method (200) of claim 1, wherein determining the Manhattan distance comprises:
tokenizing each of the plurality of existing requirements and the new requirement into a corresponding set of tokens; and
determining the Manhattan distance between each of the plurality of existing requirements and the new requirement based on a difference between the corresponding set of tokens for each of the plurality of existing requirements and the corresponding set of tokens for the new requirement.
5. The method (200) of claim 4, wherein determining the relevancy score comprises:
converting each of the one or more identified existing requirements and the new requirement into respective binary vectors, wherein an attribute of 1 in a binary vector corresponds to a presence of a corresponding token, and wherein a total number of attributes in the binary vector correspond to a total number of tokens in a union of the one or more corresponding set of tokens; and
determining the relevancy score for the each of the one or more identified existing requirements with respect to the new requirement based on a cosine similarity between the respective binary vectors.
6. A system (100) for facilitating designing of an Internet of Things (loT) infrastructure
for deploying an loT application, the system (100) comprising:
a processor; and
a memory communicatively coupled to the processor, wherein the memory stores processor-executable instructions, which, on execution, causes the processor to:
determine (201) a Manhattan distance between each of a plurality of existing requirements and a new requirement, wherein the new requirement is with respect to the loT infrastructure for deploying the loT application;
identify (202) one or more of the plurality of existing requirements corresponding to a minimum Manhattan distance;
determine (203) a relevancy score for each of the one or more identified existing requirements based on a similarity between the each of the one or more identified existing requirements and the new requirement; and

provide (204) one or more loT components and one or more loT designs corresponding to a similar existing requirement for facilitating designing of the loT infrastructure, wherein the similar existing requirement comprises one of the one or more identified existing requirement with a maximum relevancy score.
7. The system (100) of claim 6, wherein the processor-executable instructions further
cause the processor to:
receive the new requirement from a user or a system, wherein the new requirement comprises at least one of a task to be performed, an amount of dataflow required, and a load handling capacity required; and
retrieve the plurality of existing requirements from a database (103), wherein the database (103) comprises a blockchain distributed ledger (111), wherein each of the plurality of existing requirement is retrieved along with one or more corresponding loT components and one or more corresponding loT designs, and wherein the plurality of existing requirements correspond to the new requirement.
8. The system (100) of claim 7, wherein the processor-executable instructions further
cause the processor to update the database (103) by storing the new requirement, the
one or more loT components, and the one or more loT designs for subsequent use.
9. The system (100) of claim 6, wherein the processor determines the Manhattan
distance by:
tokenizing each of the plurality of existing requirements and the new requirement into a corresponding set of tokens; and
determining the Manhattan distance between each of the plurality of existing requirements and the new requirement based on a difference between the corresponding set of tokens for each of the plurality of existing requirements and the corresponding set of tokens for the new requirement.

10. The system (100) of claim 9, wherein the processor determines the relevancy score by:
converting each of the one or more identified existing requirements and the new requirement into respective binary vectors, wherein an attribute of 1 in a binary vector corresponds to a presence of a corresponding token, and wherein a total number of attributes in the binary vector correspond to a total number of tokens in a union of the one or more corresponding set of tokens; and
determining the relevancy score for the each of the one or more identified existing requirements with respect to the new requirement based on a cosine similarity between the respective binary vectors.