ESH6 TCP VS UDP Socket Connection | Telit Cinterion IoT Developer Community
April 17, 2020 - 10:49pm, 8358 views
I am facing one strange issue on TCP Socket connection. With TCP connection my data sent success rate is only 50 percent. Basically the device is unable to send data to the server using TCP Socket. However, as soon as i change the port to UDP it sends data to the server.
Could u Please verify the commands?
TCP Connection
AT^SICS?
^SICS: 0,"conType","GPRS0"
^SICS: 0,"apn","iot.aer.net"
^SICS: 1,"conType",""
^SICS: 2,"conType",""
^SICS: 3,"conType",""
^SICS: 4,"conType",""
^SICS: 5,"conType",""
OK
AT^SCFG="Tcp/WithURCs","on"
^SCFG: "Tcp/WithURCs","on"
OK
AT^SISS=0,srvType,"Socket"
OK
AT^SISS=0,conId,0
OK
AT^SCFG="Gpio/mode/RING0","std"
^SCFG: "Gpio/mode/RING0","std"
OK
AT^SCFG="URC/Ringline","asc0"
^SCFG: "URC/Ringline","asc0"
OK
AT^SCFG="MEShutdown/sVsup/threshold","-4"
^SCFG: "MEShutdown/sVsup/threshold","-4","-4"
OK
AT^SISS=0,address,"socktcp://xx.xx.xx.xx:30000"
OK
AT^SISO=0
OK
AT^SISC=0
OK
UDP Commands
AT^SICS?
^SICS: 0,"conType","GPRS0"
^SICS: 0,"apn","iot.aer.net"
^SICS: 1,"conType",""
^SICS: 2,"conType",""
^SICS: 3,"conType",""
^SICS: 4,"conType",""
^SICS: 5,"conType",""
OK
AT^SCFG="Tcp/WithURCs","on"
^SCFG: "Tcp/WithURCs","on"
OK
AT^SISS=0,srvType,"Socket"
OK
AT^SISS=0,conId,0
OK
AT^SCFG="Gpio/mode/RING0","std"
^SCFG: "Gpio/mode/RING0","std"
OK
AT^SCFG="URC/Ringline","asc0"
^SCFG: "URC/Ringline","asc0"
OK
AT^SCFG="MEShutdown/sVsup/threshold","-4"
^SCFG: "MEShutdown/sVsup/threshold","-4","-4"
OK
AT^SISS=0,address,"sockudp://xx.xx.xx.xx:30003"
OK
AT^SISO=0
OK
^SISW: 0,1
AT^SISW=0,63
^SISW: 0,63,0
OK
With the UDP success rate is 100 percent and at the Server side there is no difference. I mean the port is open.
Hello,
Generally TCP should be more reliable because there's a connection established and retransmissions mechanism. On the other hand UDP is lighter because it's connection-less and there's smaller data consumption. Poor signal quality could also contribute to data transmission problems. I think you should also verify this. Please paste some log with the failure. Please check what errors you get (AT^SISE=<srvProfileId>, AT+CEER).
Regards,
Bartłomiej
Hi Bartłomiej,
Please find the logs with CMEE=2, CEER and SISE command.
CASE1:
//UDP Logs
AT^SISE=0
^SISE: 0,0
OK
AT^SISS=0,address,"sockudp://xx.xx.xx.xx:30003"
OK
AT+CEER
+CEER: "No report available"
OK
AT^SISO=0
OK
AT+CEER
+CEER: "No report available"
OK
^SISW: 0,1
AT^SISW=0,63
^SISW: 0,63,0
OK
^SISW: 0,1
AT
OK
AT^SISW=0,348
^SISW: 0,348,0
OK
^SISW: 0,1
AT
OK
AT^SISC=0
OK
//TCP Logs with CEER and SISE
AT^SISE=0
^SISE: 0,0
OK
AT^SISS=0,address,"socktcp://xx.xx.xx.xx:30000"
OK
AT+CEER
+CEER: "No report available"
OK
AT^SISO=0
OK
AT+CEER
+CEER: "No report available"
OK
^SIS: 0,0,91,"PDP: internal error 2"
^SIS: 0,0,91,"PDP: internal error 2"
AT^SISC=0
OK
CASE2:
//TCP Logs
AT^SISS=0,address,"socktcp://xx.xx.xx.xx:30000"
+CME ERROR: operation not allowed
AT^SISO=0
+CME ERROR: operation temporary not allowed
AT^SISC=0
OK
//UDP Logs
AT^SISS=0,address,"sockudp://xx.xx.xx.xx:30003"
OK
AT^SISO=0
OK
^SISW: 0,1
AT^SISW=0,348
^SISW: 0,348,0
OK
^SISW: 0,1
AT
OK
AT^SISC=0
OK
CASE 3:
//TCP LOGS
AT^SISS=0,address,"socktcp://xx.xx.xx.xx:30000"
OK
AT^SISO=0
OK
^SIS: 0,0,50,"Fatal: Service has detected an internal error"
AT^SISE=0,AT+CEER
+CME ERROR: unknown
AT^SISC=0
OK
AT^SISC=0
OK
//UDP Logs
AT^SISS=0,address,"sockudp://xx.xx.xx.xx:30003"
OK
AT^SISO=0
OK
^SISW: 0,1
AT^SISW=0,350
^SISW: 0,350,0
OK
^SISW: 0,1
AT
OK
AT^SISW=0,350
^SISW: 0,350,0
OK
^SISW: 0,1
AT
OK
AT^SISE=0,AT+CEER
+CME ERROR: unknown
AT^SISC=0
OK
Hi Bartłomiej,
Is there is any way to check the IPAddr which we get after session setup? I have used SICI command
AT^SICI?
^SICI: 0,2,1,"10.226.254.91"
OK
This gives me local IP assigned.
Hi,
Please try AT^SISO? - it should give you a local and remote address.
Indeed you are getting some errors. In case of 'operation temporary not allowed' it could be possible that the previous connection was not closed or htere's some other reason why the service can't be open at the moment. For other errors to really get more information you'd have to see TCP traces or module traces. What you can do is to make sure what is the network quality when this happens (for instance AT^SMONI reply) because it can also have an influence. As for SISE and CEER these commands can give an error description (if any available) while sent after the error occured only. Please also verify with some other server or SIM provider. Is it possible to establish some other connection (TCP or UDP) after the error occured or you need to reboot or do some other actions? Did you make sure that the UDP packets sent from the module were actually received by the other party?
Please check 'ATI1' command reply for the firmware version.
Regards,
Bartłomiej
Hi Bartłomiej,
We have tried everything -
1. Packets sent by UDP is successfully received by third party (Checked and verified).
2. AT^SMONI during UDP and TCP
^SMONI: 3G,9811,255,-14.0,-114,310,260,9E22,964CEA5,4,1,NOCONN //UDP
^SMONI: 3G,9811,280,-12.0,-104,310,260,9E22,964CFA1,6,11,NOCONN //TCP
3. ATI1
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.31
4. AT^SISO? on Socket vs Transparent
^SISO: 0,"Socket",2,1,0,0,"0.0.0.0:0","0.0.0.0:0"
^SISO: 1,""
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
----------------
^SISO: 0,""
^SISO: 1,"Transparent",2,1,0,0,"0.0.0.0:0","0.0.0.0:0"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO:
5. I agree with your point "In case of 'operation temporary not allowed' it could be possible that the previous connection was not closed that is why the service can't be open at the moment."
But I am hitting SISC command to close the connection. What else i can do? Sometimes even we are hitting GSM sleep command as well. After GSM wake up we are doing registeration again.
Hello,
The network quality is relatively bad - this may be the case here. But I'd suspect UDP to also have problems in such a case. Maybe it works better in this circumstnces becasue it's lighter and less data need to be sent. Anyway I suggest testing with other operator and server for comparison. Your firmware is not the latest, you might try the update but it will probably not change anything here. If you want to see the addresses in AT^SISO? reply you need to send the command when the connection is open.
Regards,
Bartłomiej
Hi Bartłomiej,
Thanks for your valuable inputs.
Here is my output for SISO after TCP request: It gave me the Tcp server address not the IPAddress which we get after the session setup?
AT^SISS=1,address,"socktcp://xx.xx.xx.xx:30000"
OK
AT^SISO=1
OK
AT^SISO?
^SISO: 0,""
^SISO: 1,"Transparent",3,1,0,0,"10.238.223.34:0","xx.xx.xx.xx:30000"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
I have two more questions:
1. Could you suggest closing authentication also? We have noticed that when we are unable to open a new session on the TCP server it shows the previous session is not closed yet. Although, we are hitting AT+SISC=0.
2. What type of connection do you recommend for TCP/UDP - "Socket" or "Transparent"? Which one is more reliable?
Hi Bartłomiej,
Could you please check SISO output and above two questions raised by me.
I appreciate your help.
Hello,
In that case you probably can only verify the IP by sending ping to the server with AT^SISX command.
Using AT+SISC command once should be enough. Maybe there's some other reason of 'operation temporary not allowed' then. But it is hard to say what it could be. For test you could try to configure and open the connection with another profile ID.
As for transparent connection the data transmission can be faster if you don't need to use AT commands for sending or receiving of each 1500 bytes. If the amount of data to send or receive is small the nontransparent version might be just a bit simpler. But there should be no difference in reliability.
Best regards,
Bartłomiej
Hi Bartłomiej,
Is there is any other way to close the already opened connection apart from SISC?
Pages