I have a doubt about the IoT Protocol Stack .
Searching between papers on google scholar or IEEE about IoT , i find the actual "IoT Protocol Stack" :
IoT Stack
I think it is uncorrect .
The doubt is about the transport layer and application layer.
1) why there is only CoAP on the application layer if there are many others Application Layer Protocol for the IoT , such as : MQTT, XMPP ,AMQP , WebSockets and so on?
2) Why they provide only UDP at the Transport layer if in the upper layer ( Application) there are some important protocol in the environment of the IoT , for example MQTT, that run over TCP ?
The term "IoT" is used with various meanings by different interest groups; so is therefore the term "IoT stack".
What the linked image depicts is the IETF IoT Stack, which is the IETF's idea of what IoT devices should use to deserve that name. CoAP is the application protocol specified by IETF (and used by various others like OMA LwM2M, OCF or Thread), and is in my experience the best suited protocol as it allows full operation on tiny devices (technically: Class 0 according to RFC 7228 – good luck implementing XMPP, WebSockets or similar on those) while still being powerful enough to express all the concepts from the HTTP web.
The image depicting only UDP is probably due to the focus on IoT devices: While CoAP can be transmitted over several transport layers (including TCP and WebSockets, but also SMS in a draft version), those transports are rather used indirectly (eg. by a browser application that uses a gateway to talk to UDP connected devices), the expected scenario for the devices themselves is using CoAP over UDP on a 6LoWPAN network. That doesn't rule out other deployment scenarios (eg. LwM2M uses CoAP over cellular networks a lot, in UDP and TCP transports), but is better seen as typical example for the smallest of devices.
Related
I would like to create a point-to-point connection between a LoRa temperature sensor and a M5 Stack (ESP32) with LoRa module. However, I am a beginner with LoRa, so I have a few questions:
Are all packets send with LoRa (not LoRaWAN) encrypted? Or does it depend on the producer of the LoRa sensor?
Can the content of the packet received by the M5 Stack be viewed? (If I understand correctly, with the LoRaWAN the content can only be viewed after it is on the server).
Can I send measured temperatures from multiple LoRa sensors to one M5 Stack? If yes, how could I distinguish from which sensor the packet has been sent?
Any help would be appreciated!
LoRa means only the RF modulation. All crypto happens in higher layers, i.e. the protocol stack – one possible option for this is LoRaWAN. LoRaWAN uses AES-128 encryption in two layers, Network and Application. You gave no information about the kind of "LoRa temperature sensor" you have, so it is not possible to make a statement about that, other than that it is not LoRaWAN. So this fully depends on the sensor's firmware. There are alternative protocol stacks to LoRaWAN, DASH7 for example. You also might want to have a look at this Stack Overflow article
This too depends on the used protocol stack. With LoRaWAN, you need a gateway to receive the node's LoRa telegrams which are then forwarded to the LoRaWAN cloud (TTN/TTS, for example). Your application can get them from there via Internet. If there's already a TTN gateway in reach, your nodes would automatically use that.
You can actually use the M5 with its WLAN capability to act as a message consumer for multiple nodes by subscribing to the cloud via MQTT, for example – using LoRaWAN. Using LoRa without LoRaWAN, this again depends on the alternative protocol stack you are using here. Of course this requires a working WLAN in reach.
If you are trying to use plain LoRa, which is possible, it is purely your task to implement all the requirements for managing the communication between all involved nodes; it is also your responsibility to ensure that the legal obligations are met.
I would strongly recommend using LoRaWAN and TTN/TTS as it is the de-facto standard for LoRa communications and offers a complete ecosystem that can be used readily without great effort/cost.
I have been reading about the SCTP, SS7 and SIGTRAN protocol. But I have a few doubts, I would like to know if someone who specializes more in networks can answer it. (I am a security auditor)
Can the SCTP protocol be used in other fields than just telephone communication (landline and mobile)?
Could it be said that the SS7 protocol is similar to the Internet Protocol (IP) but in telephony?
What is the most significant difference between SS7 and SIGTRAN?
Finally, is a PSTN (Public Switched Telephone Network) only for fixed telephony (homes) or also for mobile telephony (Cellular)?
Thank you for your answer,
Can the SCTP protocol be used in other fields than just telephone communication (landline and mobile)?
Yes, it can be used in other fields. SCTP is a protocol in the Transport Layer of the Internet Protocol Suite, that has its own advantages and disadvantages. For example it is used in WebRTC for the Data Channel.
Could it be said that the SS7 protocol is similar to the Internet Protocol (IP) but in telephony?
SS7 is not a single protocol but a set of telephony signalling protocols that includes protocols from all OSI layers so the comparison to a single (IP) protocol is not correct.
What is the most significant difference between SS7 and SIGTRAN?
SIGTRAN is SS7 over IP. The application layer protocols are the same (MAP, ISUP, CAMEL, ...) while the physical to transport layer (1 to 4) protocols are different. In SS7 you have MTP 1, 2 and 3 while in SIGTRAN you have IP, SCTP, M2PA, M2UA, M3UA, SUA protocols.
Finally, is a PSTN (Public Switched Telephone Network) only for fixed telephony (homes) or also for mobile telephony (Cellular)?
According to Wikipedia the PSTN includes the mobile networks.
Originally a network of fixed-line analog telephone systems,
the PSTN is now almost entirely digital in its core network
and includes mobile[1] and other networks, as well as fixed telephones.[1]
I have recently developed a GPRS communication software using Arduino (embedded application) and GSM modem to communicate to/fro from web server. However I found that there is enough delay and request getting dropped (response timeout) while receiving a response from server at client side.
The techniques I have tried are - TCP / UDP / HTTPS / HTTP.
In my case our requirement is for a Reliable, Fast, Guarantee Communication between client and server.
Please let me know which communication stack would establish the same or rather be best to be used?
Thanks in advance
GPRS gives you direct IP access to the Internet. If you're losing packets or suffering large delays when sending packets to your server then this sounds like a problem with the mobile ISP.
As Ken mentioned GPRS will provide you IP connectivity to the internet (or some private network if applicable).
On top of IP you can choose to use a number of higher layer protocols, the two most common of which are probably UDP and TCP.
UDP is 'connectionless' and provides very little in the way of error detection/correction etc.
TCP is connection orientated (which means that some signalling happens back and forth to establish a virtual 'connection' first). It also includes mechanisms to provide error detection, error correction and correct packet delivery order. TCP also includes flow control, to avoid the sender overloading the receiver, and congestion control to avoid network overload.
There is a perception that UDP is faster than TCP, but I think it depends on the situation - take a look at this discussion for some further discussion on speed, reliability etc between UDP and TCP (go down through all the high scored answers):
UDP vs TCP, how much faster is it?
For your requirements, I would think a solution based on TCP/IP is probably what you want.
Whether you want to use HTTP or some other protocol on top of that is going to be dependent on your solution, and to some extent on personal preference.
If MQTT is already a lightweight protocol and it uses small amount of power and bandwidth, then why do we have MQTT-SN? When is it appropriate to use MQTT and when MQTT-SN?
There are few advantages in MQTT-SN (SN for Sensors Network) over MQTT, especially for embedded devices.
Advantages
MQTT-SN uses topic ID instead of topic name. First client sends a registration request with topic name and topic ID (2 octets) to a broker. After the registration is accepted, client uses topic ID to refer the topic name. This saves media bandwidth and device memory - it is quite expensive to keep and send topic name e.g: home/livingroom/socket2/meter in memory for each publish message.
Topic name to topic ID can be configured in MQTT-SN gateway, so that topic registration message can be skipped before publish.
MQTT-SN does not require TCP/IP stack. It can be used over a serial link (preferred way), where with simple link protocol (to distinguish different devices on the line) overhead is really small. Alternatively it can be used over UDP, which is less hungry than TCP.
Disadvantages
You need some sort of gateway, which is nothing else than a TCP or UDP stack moved to a different device. This can also be a simple device (e.g.: Arduino Uno) just serving multiple MQTT-SN devices without doing other job.
MQTT-SN is not well supported.
If you are running out of resources, or you do not have Ethernet/Wifi in your device, use MQTT-SN.
MQTT-SN (wher SN means Sensors Network) is different from MQTT.
MQTT goes over TCP/IP and it can used for LAN communication or over Internet and the Cloud (if you have a client inside your network but the broker is outside on Internet).
MQTT-SN can be used on more protocols suited for sensors network like ZigBee, Z-Wave and so on.
The specification is different from MQTT ... so it isn't MQTT not over TCP/IP.
It's more lightweight and needs a bridge to translate MQTT-SN messages into MQTT messages.
Paolo.
I have gone through various udp based P2P Technology like Stun . I have implemented UDP/TCP hole punching recently for implementing p2p.
I found there are other technology as for like ICE,UPnP and teredo
Can any body tell me what is the difference between these technology.
Which one is the latest technology/protocol used for P2P in recent year.
It will good If any can provide comparative analysis on various UDP based P2P protocols.
Any link or suggestion will appreciated.
ICE stands for Interactive Connectivity Establishment. It is a protocol for NAT traversal (i.e., punching holes) supported by the IETF. There has been several reviews and evolutions of the RFC. Some may find the specifications overkill in general or unclear when it comes to performing TCP NAT traversal.
UPnP is a technology helping local devices finding each other and start communicating automatically. It implements IGD for NAT traversal, which allows remote configuration of the NAT/Router (when possible) to redirect WAN traffic to the device. Unfortunately, this method is a huge threat to security, since any application could hijack NATs/routers to let any undesirable traffic come in.
Teredo is not really related to P2P or NAT traveral. If you have an IPv6 device A on a ipv4 LAN (for example), it won't be able to connect using ipv6 to a remote ipv6 enabled device B located on the WAN. Teredo allows A to communicate with B with ipv6 by transporting ipv6 over ipv4. Teredo is massaging the frictions between ipv4 and ipv6, so to speak.
None of these technologies is 'dominating' P2P for now. It is still a boiling environment.