Telemedicine and satelite

[Geoffrey Leach]

Telemedicine requires real-time video and audio interchange with a medicalprofessional. Its becomming more common, especially these days. My experience with on attempt at a telemedicine session suggests that satelite latency makes this impractical, at best.

Questions: is my diagnosis of the problem correct? If so, would a short-term (say 30 min) bandwith increase be practical. Might there be other solutions?

[maratsade · Accepted solution]

Bandwidth increases wouldn't change latency, as latency is a result of the distance between the satellite and your site. 

[Geoffrey Leach · Accepted solution]

OK. So what else explains the breaking up of transmission?

[maratsade · Accepted solution]

Latency + congestion

Congestion = traffic on the beam, which is the geographic area the satellite signal covers.

Too  many people using the system at the same time in the same geographical area overloads the system's capacity. 

*I am not a Hughesnet employee or representative. This is a customer-to-customer tech support community, and I am a customer.

[MarkJFine · Accepted solution]

Telemedicine is not that much different from streaming, and streaming is not the same as downloading a single file. You're not getting a whole file when you stream. You're getting packets of smaller video/audio segments that require regular handshaking to ensure each packet is complete and received in the correct order. Each handshake requires several pings back and forth which may be delayed by different times. Whether the handshake was received by the server in time for the next packet and/or how not receiving it at all is interpreted by the server determines if the stream is halted in a 'buffered' state or not. Making matters worse, telemedicine and other forms of video conversations (e.g., Skype, Facetime) are more complex than this because they're trying to synchronize in both directions, not just one.

[maratsade · Accepted solution]

Bandwidth increases wouldn't change latency, as latency is a result of the distance between the satellite and your site. 

[Geoffrey Leach · Accepted solution]

OK. So what else explains the breaking up of transmission?

[maratsade · Accepted solution]

Latency + congestion

Congestion = traffic on the beam, which is the geographic area the satellite signal covers.

Too  many people using the system at the same time in the same geographical area overloads the system's capacity. 

*I am not a Hughesnet employee or representative. This is a customer-to-customer tech support community, and I am a customer.

[MarkJFine · Accepted solution]

Telemedicine is not that much different from streaming, and streaming is not the same as downloading a single file. You're not getting a whole file when you stream. You're getting packets of smaller video/audio segments that require regular handshaking to ensure each packet is complete and received in the correct order. Each handshake requires several pings back and forth which may be delayed by different times. Whether the handshake was received by the server in time for the next packet and/or how not receiving it at all is interpreted by the server determines if the stream is halted in a 'buffered' state or not. Making matters worse, telemedicine and other forms of video conversations (e.g., Skype, Facetime) are more complex than this because they're trying to synchronize in both directions, not just one.

[maratsade]

I'm bookmarking that, @MarkJFine 

My firm is using Zoom for our meetings. Even w/o the camera enabled, the thing consumes an enormous amount of data, and has contributed to my having used over half my allowance with 21 days remaining in the billing cycle.   I bought some tokens just in case. 

[MarkJFine · Accepted solution]

In my haste I meant to add that if the server deems the packet wasn't recieved, when in fact it just got the handshake late, it may attempt to resend the packet anyway, resulting in using twice the data.