Hi Vishal

Any system that is developed will be no faster than the weakest link. So you need to search for the bottleneck, identify where it is at, and work out how to deal with it.

So, in your case, if the bottleneck is at the IoT device, there is likely nothing to be gained from making improvements in the connection between the gateway and the cloud. And it may be the case that there is no point in improving the connection between the IoT device and the gateway.

You need to start by analysing every component in your system in order to find out the maximum capacity it can consistently deal with. You then need to assess the capability of the connection between each component of the system and then next in the chain, to establish what the maximum throughput capacity is, and finally the throughput to the cloud.

Think of it like you would a large river system. High in the mountains, rain falls, or snow melts and the water drains into the ground. Eventually it becomes waterlogged and it starts to form a little tributary, many of which will flow into a stream, which grows bigger and bigger the further the system flows. If the ground is very dry, the water is instantly absorbed into the ground, and there is no flow downstream. Liken this to your IoT sensors. The barrier to information flow here is the dry ground which diverts the flow. Once you overcome this problem, when the ground becomes waterlogged, tributaries start to flow. Liken this to resolving the congenstion at the IoT devices. Many tributaries, covering a wide area eventually flow into streams. Liken this to the aggregation of data collection from many IoT devices. Let us say there is a dry lake bed in the way. Liken this to a congenstion between IoT device collection and the gateway. Until the lake is full, the water will not flow past it. Once the lake fills, water will flow over the edge into a waterfall. Liken this to the congestion between gateway and cloud. Once the water flows beyond this point, nothing can stop it until it reaches the sea. Liken this to outflow from the gateway to cloud connection being de-congested, where the cloud can be expanded to absorb all data flows.

Given the infinite scalability offered by cloud services, that end is unlikely to be at issue. Simply add more resources, whether compute, or storage, or network and you will handle whatever you need to throw at it. So identify the specific capacity of each of these elements in your cloud architecture to discover what your maximum flow rates are. Now, if we liken the waterfall to the internet, check your maximum flow rate through the internet. If this is less that the cloud you have specified, either change internet supplier to a faster package, or reduce the capacity of the cloud services you are running to match.

Now repeat this exersise all the way through to the individual IoT data sensors to identify what the various maximum flow rate capacities are, the total number of these feeding into your system, and check your sums to find the bottleneck.

If the bottleneck is at the IoT sensors, perhaps you either have sensors that don't have enough capacity, or you are sampling your data too frequently. IoT sensors are very cheap, and it may be that the software you are running on them is too bloated. You may be able to find much more compact software. Or you can replace them with better capacity sensors, or you can drop your data collection frequency.

If the bottleneck is between the sensors and the gateway, then you need to analyse traffic patterns. If the data comes in high and low spurts, you could do data collection, then re-transmit collected data in a steady stream to the gateway. Or if you have too many sensors, you need to consider whether you need additional gateway capacity, or could you use the data collector to spread the load.

As for the congestion between gateway and cloud, you can add aditional resources as needed to solve the problem.

The bottom line is you need to measure all the throughputs of all the components so that you are aware of what your spare capacity will be throughout the system architecture. Some components will be far more expensive to scale than others. So you need to do your sums to discover where the cheapest point would be to expand capacity. The IoT has an infinite capacity to create data, so finding the most cost effective route to acquiring and collecting that data is essential. Equally, you do not want to be paying for more cloud services than you absolutely need, especially where the systems will run 24/7 365 days a year. The costs can really stack up.

I hope this gets you started.

Regards

Bob

If you speak about congestion of the network layer, TCP will handle it. Do not worry about it. If the congestion in servers (Cloud), administrators should add more resources and manage the cloud to reduce it. This happened in pokemon game. The good thing about IoT that it is build over the Internet. Internet arch is working in a good way from long time.

Can IoT work without cloud. Yes, what about private IoTs, these systems have thier own servers. What about WSN as IoT, they donot need cloud.   

Hi Vishal

Any system that is developed will be no faster than the weakest link. So you need to search for the bottleneck, identify where it is at, and work out how to deal with it.

So, in your case, if the bottleneck is at the IoT device, there is likely nothing to be gained from making improvements in the connection between the gateway and the cloud. And it may be the case that there is no point in improving the connection between the IoT device and the gateway.

You need to start by analysing every component in your system in order to find out the maximum capacity it can consistently deal with. You then need to assess the capability of the connection between each component of the system and then next in the chain, to establish what the maximum throughput capacity is, and finally the throughput to the cloud.

Think of it like you would a large river system. High in the mountains, rain falls, or snow melts and the water drains into the ground. Eventually it becomes waterlogged and it starts to form a little tributary, many of which will flow into a stream, which grows bigger and bigger the further the system flows. If the ground is very dry, the water is instantly absorbed into the ground, and there is no flow downstream. Liken this to your IoT sensors. The barrier to information flow here is the dry ground which diverts the flow. Once you overcome this problem, when the ground becomes waterlogged, tributaries start to flow. Liken this to resolving the congenstion at the IoT devices. Many tributaries, covering a wide area eventually flow into streams. Liken this to the aggregation of data collection from many IoT devices. Let us say there is a dry lake bed in the way. Liken this to a congenstion between IoT device collection and the gateway. Until the lake is full, the water will not flow past it. Once the lake fills, water will flow over the edge into a waterfall. Liken this to the congestion between gateway and cloud. Once the water flows beyond this point, nothing can stop it until it reaches the sea. Liken this to outflow from the gateway to cloud connection being de-congested, where the cloud can be expanded to absorb all data flows.

Given the infinite scalability offered by cloud services, that end is unlikely to be at issue. Simply add more resources, whether compute, or storage, or network and you will handle whatever you need to throw at it. So identify the specific capacity of each of these elements in your cloud architecture to discover what your maximum flow rates are. Now, if we liken the waterfall to the internet, check your maximum flow rate through the internet. If this is less that the cloud you have specified, either change internet supplier to a faster package, or reduce the capacity of the cloud services you are running to match.

Now repeat this exersise all the way through to the individual IoT data sensors to identify what the various maximum flow rate capacities are, the total number of these feeding into your system, and check your sums to find the bottleneck.

If the bottleneck is at the IoT sensors, perhaps you either have sensors that don't have enough capacity, or you are sampling your data too frequently. IoT sensors are very cheap, and it may be that the software you are running on them is too bloated. You may be able to find much more compact software. Or you can replace them with better capacity sensors, or you can drop your data collection frequency.

If the bottleneck is between the sensors and the gateway, then you need to analyse traffic patterns. If the data comes in high and low spurts, you could do data collection, then re-transmit collected data in a steady stream to the gateway. Or if you have too many sensors, you need to consider whether you need additional gateway capacity, or could you use the data collector to spread the load.

As for the congestion between gateway and cloud, you can add aditional resources as needed to solve the problem.

The bottom line is you need to measure all the throughputs of all the components so that you are aware of what your spare capacity will be throughout the system architecture. Some components will be far more expensive to scale than others. So you need to do your sums to discover where the cheapest point would be to expand capacity. The IoT has an infinite capacity to create data, so finding the most cost effective route to acquiring and collecting that data is essential. Equally, you do not want to be paying for more cloud services than you absolutely need, especially where the systems will run 24/7 365 days a year. The costs can really stack up.

I hope this gets you started.

Regards

Bob

The previous answers are good, although I'm not sure whether they answer your specific questions. I'm having some trouble understanding if we assume IoT to be the same thing!

Suppose in general architecture, either between IoT devices and gateway or between gateway and cloud.

Okay, I agree that IoT may be localized only in your own premises, or you might be using the Internet to access some so-called "IoT devices" far away.

Is there any architecture available for IoT, that don't consider cloud part for accessing resources?

Sure. You might have a lot of sensors and other devices right at home (or on the factory floor, or on a mobile platform), all accessible locally, and probably most accessible only locally. If for no other reason, security.

Is IoT handle end-to-end congestion or not?

The "I" in "IoT" means Internet, implying that IP is used. Congestion control is inherent in TCP, and can be added to UDP via an upper layer, such as what RTP/RTCP does for streaming media. So congestion control is certainly part of the mix, although in most cases, people assume IoT devices to be low power and low bandwidth, and not likely to overwhelm their network.

Where to handle Congestion Control in IoT?

Same place that congestion control is always addressed, in IP communications. I would bet that IoT operating over WiFi, in a typical home, would have no congestion issues at all. And ISP networks that have been progressively improved over the years, to the point that these networks can carry a considerable amount of TV streaming traffic, may also not have too much of a problem with "IoT." It depends entirely on what you call "IoT."

Thanks to all.

What about in terms of CoAP?

CoAP would be used to handle congestion. Where this protocol works in terms of accessing resources. at gateway or on devices?

in terms of CoAP you have two options according to the architecture that you are working on i.e either centralized or distributed. in the  centralized  architecture you can access the resource using resource directory . Otherwise, it also depends on what you want and the network itself,  here you can use GWs or directly access the nodes themselves.

The IoT plays an instrumental role here by collecting data from various sources such as traffic cameras, commuters’ mobile phones, vehicles’ GPS, sensors on the roads, passing vehicles and so on. This data is analyzed to understand traffic flows and usage patterns, enabling us to find new ways to optimize the most frequently used roads and transportation methods. Connected loop detectors that monitor conditions on roads can also detect hazardous conditions. Accordingly, maintenance crews are then dispatched to respond in a timely manner. Vehicle drivers are also warned about hazardous conditions to avoid, thus reducing the number of road accidents and increasing overall safety and security.

CoAP would become the standard protocol to enable interaction between

devices.

Thanks Reema and Majd Alsoud.

Dear Vishal Rathod,

According to your problem.

I think it is one of the optimization problems.

To handle the end-to-end congestion i.e. congestion from source to destination ( in the Centralized or distributed system what so ever) queuing discipline has to handle efficiently by threads. The solution directly impact on jitter, packet delays variation.    

In a lot of scenarios (for example dedicated sensors), it wouldn't necessarily matter if a message was lost due to congestion (or whatever), since a later transmission of the next sensor value might still be enough information. Your central processing could be based on an understanding that a percentage of readings from all sensors would be lost.

On CoAP: this seems to me a good approach, side-stepping both HTTP and TCP, which means a simpler stack for the IoT device and avoiding complexity in the communication layers.  Sending UDP datagrams is something that can be done by the dumbest devices, even without any real concept of 'IP stack' at all.

can a dynamic server solve the congestion problem at application layer?