Claims:
1. A processor implemented method (400) for reliable communication in low bandwidths inconsistent wireless network using modified-User Datagram Protocol (m-UDP), the method comprising:
receiving (402) a request, via one or more hardware processors of a field device, to initiate a communication with a server for delivering a request message generated by an application among a plurality of applications on the field device, wherein the field device opens up bidirectional m-UDP channels on application start up to communicate with the server via a network deployed for the communication, and wherein the bidirectional m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server, and ii) a second channel for receiving response messages and request acknowledgements from the server;
determining (404), via the one or more hardware processors of the field device:
a size of the request message;
a bandwidth of the network obtained from device configuration files of the field device; and
a channel information comprising a currently available device port address of the field device allotted to the second channel;
generating (406), via the one or more hardware processors of the field device, a unique message identifier for the request message;
splitting (408), via the one or more hardware processors of the field device, the request message into a plurality of data chunks in accordance with an optimal data chunk size empirically and dynamically determined on application startup in accordance with the bandwidth of the network;
generating (410), via the one or more hardware processors of the field device, a plurality of m-UDP data packets corresponding to the plurality of data chunks, wherein each of the plurality of m-UDP data packets is a self-contained message structure generated by appending each of the plurality of data chunks with:
the unique message identifier associated with the request message;
a unique sequence number;
an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk;
the channel information indicating the second channel to the server to receive request acknowledgements and response message; and
a destination address, of the server comprising a server port address, to which the request message is to be delivered;
sequentially transmitting (412) over the first channel, via the one or more hardware processors of the field device, a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet;
receiving (414) over the second channel, via the one or more hardware processors of the field device, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet;
sending (416), via the one or more hardware processors of the field device, a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement;
continuing (418), via the one or more hardware processors of the field device, sequential transmission of the remaining plurality of m-UDP packets, via the one or more hardware processors of the field device, until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel; and
awaiting, via the one or more hardware processors of the field device, a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message, wherein the field device sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device.
2. The method as claimed in claim 1, wherein the method further comprises:
receiving (502), via one or more hardware processors of the server, the m-UDP packet over the first channel;
extracting (504), from the received m-UDP packet via the one or more hardware processors of the server i) the channel information of the second channel over which the request acknowledgement is to be sent for each of the plurality of m-UDP packet received, and ii) the unique message identifier indicating that the received m-UDP packet is of the request message;
identifying (506), via one or more hardware processors of the server:
the data chunk within the m-UDP packet; and
whether the end message delimiter is present or absent in the UDP packet;
sending (508), via the one or more hardware processors of the server, the request acknowledgement for the received m-UDP packet over the second channel in accordance with the device port address present in the extracted channel information;
performing (510) one of, via the one or more hardware processors of the server:
continuing receiving remaining of the plurality of m-UDP packets over the first channel if the end message delimiter is absent in received m-UDP packet; and
integrating the plurality of m-UDP packets received earlier over the first channel that are having the unique message identifier to regenerate the request message, if the end message delimiter is present in the received m-UDP;
converting (512), via the one or more hardware processors of the server, the request message to a http request to be processed by an application server using http/REST Application Programming Interfaces (APIs);
receiving (514) by the server the response message from the application server post processing the request message via the one or more hardware processors of the server; and
processing (516), via the one or more hardware processors of the server, the response message to generate the plurality of m-UDP response packets to be transmitted over the second channel in accordance to the extracted channel information for delivering the response message to the field device.
3. The method as claimed in claim 2, wherein processing the response message to generate the plurality of m-UDP response packets comprises:
determining a size of the response message;
splitting the response message into a plurality of response data chunks in accordance with the optimal data chunk size; and
generating the plurality of m-UDP data packets corresponding to the plurality of response data chunks by appending each of the plurality of response data chunks with:
the unique message identifier associated with the request message;
a unique response sequence number;
an end message delimiter if the response data chunk from the plurality of response data chunks is a last response data chunk; and
a destination address, of the field device comprising a device port address, to which the response message is to be delivered.
4. The method as claimed in claim 1, wherein the method further comprises enabling the plurality of applications running on the field device 102 to simultaneously communicate a plurality of request messages to the server and receive a plurality of response messages from the server by opening up a plurality of first channels and a plurality of second channels by the field device.
5. The method as claimed in claim 1, wherein the request package and the response package are converted directly to a m-UDP packet without splitting into the plurality of m-UDP packets if size of the request package and the response package is within the optimal data chunk size.

6. A system(100) for reliable communication in low bandwidths inconsistent wireless network using modified-User Datagram Protocol (m-UDP)comprising a filed device (102), a server 104 and an application server 106, the field device (102) comprising:
a memory (202) storing instructions;
one or more Input/Output (I/O) interfaces (206); and
one or more hardware processors (204) coupled to the memory (202) via the one or more I/O interfaces (206), wherein the one or more hardware processors (204) are configured by the instructions to:
receive a request to initiate a communication with a server for delivering a request message generated by an application among a plurality of applications on the field device (102), wherein the field device (102) opens up bidirectional m-UDP channels on application start up to communicate with the server (104) via a network deployed for the communication, and wherein the bidirectional m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server and ii) a second channel for receiving response messages and request acknowledgements from the server;
determine:
a size of the request message;
a bandwidth of the network obtained from device configuration files of the field device; and
a channel information comprising a currently available device port address of the field device allotted to the second channel;
generate a unique message identifier for the request message;
split the request message into a plurality of data chunks in accordance with an optimal data chunk size empirically and dynamically determined on startup in accordance with the bandwidth of the network;
generate a plurality of m-UDP data packets corresponding to the plurality of data chunks , wherein each of the plurality of m-UDP data packets is a self-contained message structure generated by appending each of the plurality of data chunks with:
the unique identifier associated with the request message;
a unique sequence number;
an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk;
the channel information indicating the second channel to the server to receive request acknowledgements and response message; and
a destination address, of the server comprising a server port address, to which the request message is to be delivered;

sequentially transmit over the first channel a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet;
receive over the second channel, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet;
send a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement;
continue sequential transmission of the remaining plurality of m-UDP packets, via the one or more hardware processors of the field device, until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel; and
await a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message, wherein the field device sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device.
7. The system (100) as claimed in claim 6, wherein the server 104 is configured to:
receive the m-UDP packet over the first channel;
extract from the received m-UDP packet i) the channel information of the second channel over which the request acknowledgement is to be sent for each of the plurality of m-UDP packet received, and ii) the unique message identifier indicating that the received m-UDP packet is of the request message ;
identify:
the data chunk within the m-UDP packet; and
whether the end message delimiter is present or absent in the UDP packet;
send the request acknowledgement for the received m-UDP packet over the second channel in accordance with the device port address present in the extracted channel information;
perform one of:
continue receiving remaining of the plurality of m-UDP packets over the first channel if the end message delimiter is absent in received m-UDP packet; and
integrate the plurality of m-UDP packets received earlier over the first channel that are having the unique message identifier to regenerate the request message, if the end message delimiter is present in the received m-UDP;
converting the request message to a http request to be processed by the application server (106) using http/REST Application Programming Interfaces (APIs);
receive from the application server (106) the response message post processing the request message; and
process the response message to generate the plurality of m-UDP response packets to be transmitted over the second channel in accordance to the extracted channel information for delivering the response message to the field device.
8. The system (100) as claimed in claim 7, wherein the server (104) is configured to process the response message to generate the plurality of m-UDP response packets comprises by:
determining a size of the response message;
splitting the response message into a plurality of response data chunks in accordance with the optimal data chunk size; and
generating the plurality of m-UDP data packets corresponding to the plurality of response data chunks by appending each of the plurality of response data chunks with:
the unique message identifier associated with the request message;
a unique response sequence number;
an end message delimiter if the response data chunk from the plurality of response data chunks is a last response data chunk; and
a destination address, of the field device comprising a device port address, to which the response message is to be delivered.
9. The system (100) as claimed in claim 6, wherein the field device (102) is configured to enable the plurality of applications to simultaneously communicate a plurality of request messages to the server and receive a plurality of response messages from the server by opening up a plurality of first channels and a plurality of second channels by the field device.
10. The system (100) as claimed in claim 6,
wherein the field device (102) is configured to convert the request package directly to a m-UDP packet without splitting into the plurality of m-UDP packets if size of response package is within the optimal data chunk size;
and wherein the server (104) is configured to convert the response package directly to the m-UDP packet without splitting into the plurality of m-UDP packets if size of response package is within the optimal data chunk size.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
METHOD AND SYSTEM FOR RELIABLE COMMUNICATION IN LOW BANDWIDTH INCONSISTENT WIRELESS NETWORKS USING MODIFIED-UDP

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The embodiments herein generally relate to communication networks and, more particularly, to a method and system for reliable communication in low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP).

BACKGROUND
[002] Field devices such as mobile phones, digital assistants and so on, used for field operation requires data communication with backend systems such as application servers. Operational areas, where the field operation takes place are wide and varied, in terms of topography, size, wireless type and speed of the network deployed for communication. Besides, they face challenges related to weather or dynamic operational conditions which further affects its reliability, speed and bandwidth. To maintain reliable communications, a widely used option is “http” based protocols, which is based on standard Transmission Control Protocol (TCP). However, the TCP is a heavy weight connection oriented protocol and not a good choice in low bandwidth networks where there are frequent connection drops. The reason being that application built over these TCP based protocols has inherent delays in getting the connection reestablished during frequent disconnection from the network. And, due to this frequent disconnection, the communication between the background systems and the field devices get affected.
[003] User Datagram Protocol (UDP) provides a lightweight connection less protocol, however as a communication channel suffers with problems of statelessness and unreliable multi-cast communication protocol which fails to ensure reliable delivery in some of the typical operational situations like connection drops or ordered delivery/receipt or targeted exchange. Thus, usage of UDP as-is is not recommended for low bandwidth networks where a reliable communication is expected.
[004] Attempts have been made in literature, where UDP is used to achieve reliable communication. An existing method providing Reliable User Datagram Protocol (RUDP) for Network Games uses an acknowledgment and retransmission of lost data packets to ensure reliable communication. However, in this existing RUDP based approach certain predefined number of data packets are continuously transmitted without waiting for acknowledgments for each transmitted packet. Thus, transmission of data packets and receiving of acknowledgments for corresponding data packets is not in true sequential order. This requires sequencing or ordering logic to be implemented at the receiving end for ensuring delivery of all the transmitted data packets, and wait for retransmission and reception of lost intermediate packets during transmission. Moreover, the RUDP does not explicitly detail on the acknowledgement channel and indicates use of static address during data exchange. RUDP does not address any issues related to port unavailability or change in port addresses due to constraints, specifically in field operation where continuous availability of dedicated ports may be a challenge or changes in IP addresses may occur. In such situations existing methods like RUDP would interrupt data transmission and require resetting the communication. Furthermore, the RUDP does not mention on size of data packets and implicitly refers to fixed size of data packets. Thus, if network bandwidth degrades due to any reasons such as changes in the deployed network, the reliability and speed of data transmission will degrade and will require data size reset. This will interrupt the field operations and degrade user experience.
[005] Few other UDP based approaches providing reliable communication use parallel transmission that requires buffering of data packets at receiving end. However, buffering approach can create congestion, specifically in a low bandwidth network, and in most practical scenarios does not offer a good choice as buffering reduces the data speed.

SUMMARY
[006] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a method for reliable communication in low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol.is provided.
[007] The method comprises receiving a request to initiate a communication with a server for delivering a request message generated by an application among a plurality of applications on the field device, wherein the field device opens up bidirectional m-UDP channels on application start up to communicate with the server via a network deployed for the communication. The bidirectional m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server and ii) a second channel for receiving response messages and request acknowledgements from the server.
[008] Further, determining: a size of the request message; a bandwidth of the network obtained from device configuration files of the field device; and a channel information comprising a currently available device port address of the field device allotted to the second channel.
[009] Further, generating a unique message identifier for the request message; and splitting the request message into a plurality of data chunks in accordance with an optimal data chunk size empirically and dynamically determined on startup in accordance with the bandwidth of the network.
[0010] Furthermore, generating a plurality of m-UDP data packets corresponding to the plurality of data chunks , wherein each of the plurality of m-UDP data packets is a self-contained message structure generated by appending each of the plurality of data chunks with: the unique identifier associated with the request message; a unique sequence number; an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk; the channel information indicating the second channel to the server to receive request acknowledgements and response message; and
a destination address, of the server comprising a server port address, to which the request message is to be delivered.
[0011] Further, the method comprises sequentially transmitting, over the first channel, a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet and receiving over the second channel, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet.
[0012] Further, the method comprises sending a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement; and continuing sequential transmission of the remaining plurality of m-UDP packets, via the one or more hardware processors of the field device, until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel.
[0013] Thereafter, the method comprises awaiting a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message, wherein the field device sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device.
[0014] .In another aspect, a system for reliable communication in low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol.is provided. The device comprises a memory storing instructions; one or more Input/Output (I/O) interfaces; and one or more hardware processors coupled to the memory via the one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to receiving a request to initiate a communication with a server for delivering a request message generated by an application among a plurality of applications on the field device, wherein the field device opens up bidirectional m-UDP channels on application start up to communicate with the server via a network deployed for the communication. The bidirectional m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server and ii) a second channel for receiving response messages and request acknowledgements from the server.
[0015] Further the one or more hardware processors are configured to determine: a size of the request message; a bandwidth of the network obtained from device configuration files of the field device; and a channel information comprising a currently available device port address of the field device allotted to the second channel.
[0016] Further the one or more hardware processors are configured to generate a unique message identifier for the request message; and splitting the request message into a plurality of data chunks in accordance with an optimal data chunk size empirically and dynamically determined on startup in accordance with the bandwidth of the network.
[0017] Furthermore, Further the one or more hardware processors are configured to generate a plurality of m-UDP data packets corresponding to the plurality of data chunks, wherein each of the plurality of m-UDP data packets is a self-contained message structure generated by appending each of the plurality of data chunks with: the unique identifier associated with the request message; a unique sequence number; an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk; the channel information indicating the second channel to the server to receive request acknowledgements and response message; and a destination address, of the server comprising a server port address, to which the request message is to be delivered.
[0018] Further, the one or more hardware processors are configured to sequentially transmitting, over the first channel, a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet and receiving over the second channel, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet.
[0019] Further, the one or more hardware processors are configured to sending a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement; and continuing sequential transmission of the remaining plurality of m-UDP packets, via the one or more hardware processors of the field device, until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel.
[0020] Thereafter, the one or more hardware processors are configured to await a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message, wherein the field device sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device.
[0021] In yet another aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions, which when executed by one or more hardware processors causes a method for reliable communication in low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol. The method comprises receiving a request to initiate a communication with a server for delivering a request message generated by an application among a plurality of applications on the field device, wherein the field device opens up bidirectional m-UDP channels on application start up to communicate with the server via a network deployed for the communication. The bidirectional m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server and ii) a second channel for receiving response messages and request acknowledgements from the server.
[0022] Further, determining: a size of the request message; a bandwidth of the network obtained from device configuration files of the field device; and a channel information comprising a currently available device port address of the field device allotted to the second channel.
[0023] Further, generating a unique message identifier for the request message; and splitting the request message into a plurality of data chunks in accordance with an optimal data chunk size empirically and dynamically determined on startup in accordance with the bandwidth of the network.
[0024] Furthermore, generating a plurality of m-UDP data packets corresponding to the plurality of data chunks , wherein each of the plurality of m-UDP data packets is a self-contained message structure generated by appending each of the plurality of data chunks with: the unique identifier associated with the request message; a unique sequence number; an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk; the channel information indicating the second channel to the server to receive request acknowledgements and response message; and
a destination address, of the server comprising a server port address, to which the request message is to be delivered.
[0025] Further, the method comprises sequentially transmitting, over the first channel, a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet and receiving over the second channel, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet.
[0026] Further, the method comprises sending a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement; and continuing sequential transmission of the remaining plurality of m-UDP packets, via the one or more hardware processors of the field device, until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel.
[0027] Thereafter, the method comprises awaiting a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message, wherein the field device sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device.
[0028] 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
[0029] 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:
[0030] FIG. 1 is an overview of a system for reliable communication between a field device and a server in a low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol, in accordance with some embodiments of the present disclosure.
[0031] FIG. 2 is a functional block diagram of the field device communicating with the server using the m-UDP to provide reliable communication in the low bandwidth inconsistent wireless networks, in accordance with some embodiments of the present disclosure.
[0032] FIG. 3 is a functional block diagram of the server communicating with the field device using the m-UDP to provide reliable communication in the low bandwidth inconsistent wireless networks, in accordance with some embodiments of the present disclosure.
[0033] FIG. 4A and FIG. 4B are flow diagrams illustrating a method for reliable communication in the low bandwidth inconsistent wireless networks using the m-UDP implemented at the field device of the system of FIG. 1, in accordance with some embodiments of the present disclosure.
[0034] FIG. 5A and FIG. 5B are flow diagrams illustrating steps implemented by the server of the system of FIG. 1 for reliable communication in the low bandwidth inconsistent wireless networks over the m-UDP, in accordance with some embodiments of the present disclosure.
[0035] FIG. 6 is a sequence diagram illustrating the m-UDP for small size request message and response message, in accordance with some embodiments of the present disclosure.
[0036] FIG. 7A and 7B is a sequence diagram illustrating the m-UDP for large size request message and response message, in accordance with some embodiments of the present disclosure.
[0037] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems and devices embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION OF EMBODIMENTS
[0038] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. 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 scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope being indicated by the following claims.
[0039] Embodiments herein provide a method and system for reliable communication between a field device and a server in a low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol.
[0040] Referring now to the drawings, and more particularly to FIGS. 1 through 7, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[0041] FIG. 1 is an overview of a system 100 for reliable communication between a field device 102 and a server 104 in a low bandwidth inconsistent wireless networks using a modified-User Datagram Protocol (m-UDP) protocol, in accordance with some embodiments of the present disclosure. As depicted the system 100 comprises a plurality of field devices (not shown) that communicate to the server 104 for backend processing of data generated by one or more applications running each of the one or more field devices. The system 100 enables setting up bidirectional m-UDP channels for two way communication to accommodate acknowledgements for received data at both the field device 102 end and the server 104 end. The bidirectional m-UDP channels, interchangeably referred herein as m-UDP channels, carry request messages from the field device 102 to the server 104 and request messages from the server 104 to the field device 102 by converting the plurality of m-UDP packets. The server 104 is a field gateway to an application server 106 and converts the request message in the form of m-UDP packets to a http request to be processed by an application server 106 using http/REST Application Programming Interfaces (APIs). The application server 106 performs backend processing of the data (request messages) received from the applications running on the field devices and generates the processed data (response messages) to the requesting applications, which are sent over the m-UDP channels by the server 104 by converting to the http response from the application server 106 to m-UDP packets.
[0042] It can be understood by ordinary person skilled in the art that the system is explained in context of single field device with single application running on the field device. However, the manner in which each of the field devices function for every application running on the field device so as to enable reliable communication using the m-UDP is similar are not repeated from brevity.
[0043] The system 100 enables splitting a request messages and response messages to be sent over m-UDP channels into a plurality of m-UDP packets with a specific packet size, referred as optimal data chunk size, which is determined dynamically at application start up in accordance with available bandwidth of a current network deployed for the communication. The m-UDP channels provide a bidirectional communication, which is sequential in nature, where a source node and a destination node (the field device and the server) always send a single m-UDP packet and wait for the acknowledgement before sending the next m-packet in sequence. This disclosed approach avoids any parallel communication and buffering requirement at the destination end (receiving end). Thus the system 100 follows a true sequential data packet transmission approach avoiding congestion, specifically when in low band width wireless networks.
[0044] Further, the m-UDP packet is a self-contained message structure comprising a channel information of the source node shared with the destination node via the m-UDP data packet for receiving acknowledgments and response messages from destination node. Inclusion of the channel information within the m-UDP packet enables data exchange between the field device and the server is possible even during change of network addresses like IP / Ports and change of end devices.
[0045] As mentioned above, the response message generated by processing the request message at the application server 106, in similar manner is converted into the plurality of m-UDP packets before transmitting over the m-UDP channel identified by the server from the received m-UDP packet. The m-UDP is described in detail in conjunction with FIGS. 4 through 7B
[0046] FIG. 2 is a functional block diagram of the field device 102 communicating with the server 104 using the m-UDP to provide reliable communication in the low bandwidth inconsistent wireless networks, in accordance with some embodiments of the present disclosure.
[0047] In an embodiment, the field device 102 includes a processor(s) 204, communication interface device(s), alternatively referred as input/output (I/O) interface(s) 206, and one or more data storage devices or a memory 202 operatively coupled to the processor(s) 204. The field device 102 with one or more hardware processors is configured to execute functions of one or more functional blocks of the field device 102.
[0048] Referring to the components of field device 102, in an embodiment, the processor(s) 204, can be one or more hardware processors 204. In an embodiment, the one or more hardware processors 204 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 204 are configured to fetch and execute computer-readable instructions stored in the memory 202. In an embodiment, the field device 102 can be implemented in a variety of computing systems including laptop computers, notebooks, hand-held devices such as mobile phones, personal digital assistants and the like.
[0049] The I/O interface(s) 206 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface and can facilitate multiple communications within a wide variety of networks N/W and protocol types such as the m-UDP, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface (s) 106 can include one or more ports for connecting a number of devices (nodes) of the field to one another or to another server or devices such as server 104
[0050] The memory 202 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0051] Further, the memory 202 may include a database 208, which may store request message generated by an application on the field device, the plurality of m- UDP packets created by splitting the request message and the response message received in terms of plurality of m-UDP packets sent by the server 104 and the like. The memory 202 may comprise information pertaining to input(s)/output(s) of each step performed by the processor(s) 204 of the field device 102 and methods of the present disclosure. In an embodiment, the database 208 may be external (not shown) to the field device 102 and coupled via the I/O interface 206. Functions of the components of the field device 102 are explained in conjunction with flow diagram of FIGS. 4A and 4B and sequence diagrams of FIG. 6 and 7.
[0052] FIG. 3 is a functional block diagram of the server 104 communicating with the field device 102 using the m-UDP to provide reliable communication in the low bandwidth inconsistent wireless networks, in accordance with some embodiments of the present disclosure.
[0053] In an embodiment, the server 104 includes a processor(s) 304, communication interface device(s), alternatively referred as input/output (I/O) interface(s) 306, and one or more data storage devices or a memory 302 operatively coupled to the processor(s) 304. The server 104 with one or more hardware processors is configured to execute functions of one or more functional blocks of the server 104.
[0054] Referring to the components of the server 104, in an embodiment, the processor(s) 304, can be one or more hardware processors 304. In an embodiment, the one or more hardware processors 304 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 304 are configured to fetch and execute computer-readable instructions stored in the memory 302. In an embodiment, the server 104 can be implemented in a variety of computing systems including laptop computers, cloud server, desktop and the like.
[0055] The I/O interface(s) 306 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface and can facilitate multiple communications within a wide variety of networks N/W and protocol types such as the m-UDP, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface (s) 306 can include one or more ports for connecting a number of devices (nodes) of the field to one another or to another server or devices such as server 104
[0056] The memory 302 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0057] Further, the memory 302 may include a database 308, which may store response message generated by the application server 106, the plurality of m- UDP packets created by splitting the response message, the request message received in terms of plurality of m-UDP packets from the filed device 102 and the like. The memory 302 may comprise information pertaining to input(s)/output(s) of each step performed by the processor(s) 304 of the server 104 and methods of the present disclosure. In an embodiment, the database 308 may be external (not shown) to the server 104 and coupled via the I/O interface 306. Functions of the components of the server 104 are explained in conjunction with flow diagram of FIGS. 5A and 5B and sequence diagrams of FIG. 6 and 7.
[0058] FIG. 4A and FIG. 4B are flow diagrams illustrating a method 400 for reliable communication in the low bandwidth inconsistent wireless networks using the m-UDP implemented by the field device of the system of FIG. 1, in accordance with some embodiments of the present disclosure. In an embodiment, the field device 102 comprises one or more data storage devices or the memory 202 operatively coupled to the processor(s) 204 and is configured to store instructions for execution of steps of the method 400 by the processor(s) or one or more hardware processors 204. The steps of the method 400 of the present disclosure will now be explained with reference to the components or blocks of the field device 102 as depicted in FIG. 1 and the steps of flow diagram as depicted in FIG4A and FIG. 4B and the sequence diagrams of FIG. 6 and 7. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[0059] Referring to the steps of the method 400, at step 402, the one or more hardware processors 204 of the field device 102 are configured to receive a request to initiate a communication with the server 104 for delivering a request message among a plurality of request messages generated by an application among a plurality of applications on the field device. The field device opens up m-UDP channels on application start up to communicate with the server via a network deployed for the communication, and wherein the m-UDP channels comprise i) a first channel for transmitting request message and response acknowledgements to the server, and ii) a second channel for receiving response messages and request acknowledgements from the server.
[0060] At step 404, the one or more hardware processors 204 of the field device 102 are configured to determine:
a) a size of the request message generated by the application requesting service from the application server 106.
b) a bandwidth of the network. The bandwidth of the network deployed in the field for communication between the field device 102 and the server 104 is obtained from device configuration files of the field device 102. Thus, device configuration files provide the information on any changes in a current network deployed and the bandwidth (BW) supported by that network. Thus, any upgrading or downgrading of the currently deployed network is noted by the field device 102, while setting up m-UDP channels. This BW information is then used by the field device 102 and the server 104 to decide optimal size of data packets to be transmitted over the m-UDP channels to avoid congestion and ensure reliable packet delivery.
c) a channel information comprising a currently available device port address of the field device allotted to the second channel. This is critical information as this ensures providing flexibility to the field device to select channels based on the current availability. This feature enables handling scenarios where the ports usage for consumptions on the field devices is controlled using the firewalls and the configuration.
[0061] At step 406, the one or more hardware processors 204 of the field device 102 are configured to generate a unique message identifier for the request message. It can be understood by having person ordinary skilled in the art that the application may generate one or more request messages for one or more services to be services by the application server 106. Thus each of the request message is assigned the specific unique identifier that distinctly identifies the specific request message.
[0062] The steps of the method 400 are explained in conjunction with treatment provided to one request message and should be understood that similar treatment will be provided to other request messages and not explicitly mentioned for brevity. The unique message identifier enables to distinguish the request messages at server end and accordingly respond to respective request message with associated response messages.
[0063] At step 408, the one or more hardware processors 204 of the field device 102 are configured to split, via the one or more hardware processors of the field device, the request message into a plurality of data chunks in accordance with an optimal data chunk size. This optimal data chunk size is empirically and dynamically determined on startup in accordance with the bandwidth of the network. However, if the size of the request message is within the optimal data chunk size, this will not affect the m-UDP channel performance and there is no need to split the request message. The optimal data chunk size is determined by using known tools in art that enable transmitting and receiving the UDP packets from one end to the other within the network. And as part of this exercise the tool is used to transmit the variable sizes of the m-UDP packet possible from field device to the server and vice versa. Based on the receipt of the transmitted packets on the destination end the optimal packet size is derived and set as part of the configuration files on both server and the client (field device).
[0064] At step 410, the one or more hardware processors 204 of the field device 102 are configured to generate the plurality of m-UDP data packets corresponding to the plurality of data chunks by appending each of the plurality of data chunks with:
a) the unique message identifier associated with the request message (UMI);
b) a unique sequence number (USN);
c) an end message delimiter if a data chunk from the plurality of data chunks is a last data chunk(E_MESG_DLMT);
d) the channel information indicating the second channel to the server to receive request acknowledgements and response message (CI); and
e) a destination address, of the server comprising a server port address, to which the request message is to be delivered (DSTN).
It can be understood that the server 104 port addresses will be prior known to all field devices. However, the method disclosed shares the channel information of the field device that enables the server to know the free available port address of the field device 102, that the filed device has allotted for response messages and acknowledgments from the server 104. This enables dynamic address allocation for the second channel unlike static address used by prior arts for acknowledgements. IP address and the port number of second channel is derived as part of packet transmission from the field device 102 and it is not fixed. Just before creating the data packets (m-UDP packets) the IP address and the port number are included as part of the message content. With this approach invention enables the field device to continue communication using a new channel for every message without any delays
[0065] Thus, each of the m-UDP data packet is a self-contained message structure as depicted in table 1 below:
UMI USN D1,D2 D3……….. DSTN CI E_MESG_DLMT
Appended headers Payload (data chunk) Appended Ack channel info If data chunk is last chunk of the request message

[0066] At step 412, the one or more hardware processors 204 of the field device 102 are configured to sequentially transmit over the first channel, a m-UDP data packet among the plurality of m-UDP data packets in accordance with the unique sequence number associated with the m-UDP packet.
[0067] At step 414, the one or more hardware processors 204 of the field device 102 are configured to receive over a second channel, a request acknowledgement, confirming delivery of the transmitted m-UDP data packet. Upon receiving successful delivery confirmation, at step 416, the one or more hardware processors 204 of the field device 102 are configured to send a next m-UDP data packet among the plurality of m-UDP packets upon receiving the request acknowledgement.
[0068] At step 418, the one or more hardware processors 204 of the field device 102 are configured to continue sequential transmission of the remaining plurality of m-UDP packets until the plurality of m-UDP packets are transmitted to deliver the request message over the first channel.
[0069] At step 420, the one or more hardware processors 204 of the field device 102 are configured to await a response message in terms of a plurality of m-UDP response packets from the server over the second channel in response to the delivered request message. On successfully receiving m-UDP response packets the field device 102 sends response acknowledgements over the first channel for each of the plurality of m-UDP response packets received by the field device 102. The m-UDP packets corresponding to the request message and m-UDP response packets may be in general referred as m-UDP packets.
[0070] FIG. 5A and FIG. 5B are flow diagrams illustrating a method 500 comprising steps implemented by the server 104 of the system of FIG. 1 for reliable communication in the low bandwidth inconsistent wireless networks over the m-UDP, in accordance with some embodiments of the present disclosure.
[0071] In an embodiment, the server 104 comprises one or more data storage devices or the memory 302 operatively coupled to the processor(s) 304 and is configured to store instructions for execution of steps of the method 500 by the processor(s) or one or more hardware processors 304. The steps of the method 500 of the present disclosure will now be explained with reference to the components or blocks of the server as depicted in FIG. 1 and the steps of flow diagram as depicted in FIGS. 5A and FIG. 5B and the sequence diagrams of FIGS. 6 and 7. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[0072] Referring to the steps of the method 500, at step 502, the one or more hardware processors 304 of the server 104 are configured to receive the m-UDP packet over the first channel.
[0073] At step 502, the one or more hardware processors 304 of the server 104 are configured to receive the m-UDP packet transmitted by the filed device 102 over the first channel.
[0074] At step 504, the one or more hardware processors 304 of the server 104 are configured to extracting from the received m-UDP packet i) the channel information of the second channel over which the request acknowledgement is to be sent for each of the plurality of m-UDP packet received, and ii) the unique message identifier indicating that the received m-UDP packet is of the request message.
[0075] At step 506, the one or more hardware processors 304 of the server 104 are configured to identify: the data chunk within the m-UDP packet and whether the end message delimiter is present or absent in the UDP packet.
[0076] At step 508, the one or more hardware processors 304 of the server 104 are configured to send the request acknowledgement for the received m-UDP packet over the second channel in accordance with the device port address present in the extracted channel information.
[0077] At step 510, the one or more hardware processors 304 of the server 104 are configured to performing one of: a) continue receiving remaining of the plurality of m-UDP packets over the first channel if the end message delimiter is absent in received m-UDP packet; and b) integrating the plurality of m-UDP packets received earlier over the first channel that are having the unique message identifier to regenerate the request message, if the end message delimiter is present in the received m-UDP.
[0078] If the end message delimiter is identified, then at step 512, the one or more hardware processors 304 of the server 104 are configured to convert the request message to a http request to be processed by an application server 106 using http/REST Application Programming Interfaces (APIs).
[0079] At step 514, the one or more hardware processors 304 of the server 104 are configured to receive from the application server the response message post processing the request message.
[0080] At step 516, the one or more hardware processors 304 of the server 104 are configured to process the response message to generate the plurality of m-UDP response packets to be transmitted over the second channel in accordance to the extracted channel information for delivering the response message to the field device 102. Unlike existing methods that handle UDP communication to Rest API for unidirectional communication for forwarding UDP-packets from the server to application servers, the method disclosed herein also enables REST API to UDP conversion, providing bidirectional communication. This enables sharing response messages from the applications servers back to the filed devices by the server over the UDP..
[0081] Processing the response message by the server 104 to generate the plurality of m-UDP response packets comprises:
a) determining a size of the response message;
b) splitting the response message into a plurality of response data chunks in accordance with the optimal data chunk size; and
c) generating the plurality of m-UDP data packets corresponding to the plurality of response data chunks by appending each of the plurality of response data chunks with:
the unique message identifier associated with the request message ( this enables the receiving field device to identify to which request message the response message data chunks are associated with)
a unique response sequence number ( provided to each split data chunk in sequential order enabling the server 102 know the sequence in which the data chunks are to be transmitted))
an end message delimiter if the response data chunk from the plurality of response data chunks is a last response data chunk; and
a destination address, of the field device comprising a device port address, to which the response message is to be delivered.
[0082] The m-UDP packets on the second channel follow the same self-contained data structure as shown in table 1 above.
[0083] As can be understood, there can be plurality of applications running on the field device 102 that simultaneously communicate a plurality of request messages to the server 104 and await reception of a plurality of response messages from the server 104/. Thus, in such scenario the field device 102 is configured to open up a plurality of first channels and a plurality of second channels for each application and the request and response messages are treated as explained in the method 400 and 500
[0084] FIG. 6 is a sequence diagram illustrating the m-UDP for small size request message and response message, in accordance with some embodiments of the present disclosure. The sequence diagram is understood in conjunction with flow diagrams of FIG. 4A through FIG. 5B, however, since response message size is identified to be accommodated is available network bandwidth the method processes and transmits the single request/ response message as a single m-UDP packet/ response m-UDP packet without need for splitting the request message or response message.
[0085] FIGS. 7A and 7B is a sequence diagram illustrating the m-UDP for large size request message and response message, in accordance with some embodiments of the present disclosure. Herein as described in FIG. 4A through 5B the response messages/ request messages are split in plurality of m-UDP packets in accordance with the BW of the deployed network
[0086] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[0087] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means, and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0088] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0089] 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 of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[0090] 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.
[0091] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.