Voice Traffic

[nate mail]

Hi,

I was just wondering any probability is there to transmit the voice signal through the Openthread mesh network?

Kind regards,

[nate mail]

Hi again,

I saw several Google Nest products on the Openthread website that claims they are using Openthread.

For example, Google Nest Cam IQ Indoor, Google Nest Cam IQ Outdoor.

Can I assume that using Openthread to convey the VoIP is a possible solution?

Thank you very much.

Regards,

N

[Jonathan Hui]

In short, Thread was not designed to support audio streaming applications.

Thread's physical layer supports a raw data rate at 250 kbps. After accounting for MAC overhead, multi-hop communication (Thread radios are not full duplex), and that it is an IP-based network designed to support multiple different applications simultaneously, the practical data rate is typically an order of magnitude less.

Nest Cam uses Wi-Fi for streaming audio/video - the inclusion of Thread is to support other lower data rate applications.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CALWMNKyTJLwu95h1dW5vs_OCVCVEV21_z%2BkJUgY2Bra%2BTSd1hg%40mail.gmail.com.

[nate mail]

Hi Jonathan,

Thank you very much for the information, very helpful!

Kind regards,

[Stuart Longland]

On Thu, 9 Sep 2021 13:14:01 +0100
nate mail <gusert...@gmail.com> wrote:

> I was just wondering any probability is there to transmit the voice signal
> through the Openthread mesh network?

It could be doable… data rates of around 32kbps are possible across a
Thread mesh, and that's more than sufficient for a decent voice CODEC
(should be sufficient for G.729). David Rowe's Codec2 voice CODEC
(<3kbps) may even be an option.

Where you'll come unstuck will be packet jitter, which is likely to be
very high on a Thread network. This will pretty much rule out any
low-latency streaming applications, but would be fine for sending a
recorded message.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[nate mail]

Hi,

Thank you very much for your reply.

Would you think that the TDMA will be an appropriate solution? 

If the entire Openthread network is time synchronised and we carefully allocated the time slot for all network devices, the collision issue may be relieved, then the voice transmission over Opethtread would be doable?

Kind regards,

[Stuart Longland]

On Mon, 20 Sep 2021 06:22:54 +0100
nate mail <gusert...@gmail.com> wrote:

> Thank you very much for your reply.
> Would you think that the TDMA will be an appropriate solution?
> If the entire Openthread network is time synchronised and we carefully
> allocated the time slot for all network devices, the collision issue may be
> relieved, then the voice transmission over Opethtread would be doable?

Maybe, maybe not. Even on a very quiet mesh network, there's a certain
amount of jitter:

> root@RevPi37442:~# ping6 -n fe80::ccbd:b358:925b:6fc9%wpan0
> PING fe80::ccbd:b358:925b:6fc9%wpan0(fe80::ccbd:b358:925b:6fc9%wpan0) 56 data bytes
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=1 ttl=64 time=16.9 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=2 ttl=64 time=16.3 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=3 ttl=64 time=15.5 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=4 ttl=64 time=14.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=5 ttl=64 time=17.3 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=6 ttl=64 time=16.7 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=7 ttl=64 time=15.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=8 ttl=64 time=14.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=9 ttl=64 time=15.8 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=10 ttl=64 time=14.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=11 ttl=64 time=14.2 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=12 ttl=64 time=14.2 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=13 ttl=64 time=15.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=14 ttl=64 time=14.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=15 ttl=64 time=15.4 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=16 ttl=64 time=14.6 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=17 ttl=64 time=15.8 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=18 ttl=64 time=15.8 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=19 ttl=64 time=15.7 ms
> 64 bytes from fe80::ccbd:b358:925b:6fc9%wpan0: icmp_seq=20 ttl=64 time=15.7 ms
> ^C
> --- fe80::ccbd:b358:925b:6fc9%wpan0 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 41ms
> rtt min/avg/max/mdev = 14.168/15.413/17.275/0.916 ms

916us of jitter there. That's one hop, all nodes are in direct
line-of-sight to each-other, and they've all got long-range PA/LNA
front-ends (two CC2538s with CC2592s and a nRF52840 with a SKY66122).

That's going at a fairly sedate 1 packet a second, but audio will need
a lot more, let's try the other extreme:

> root@RevPi37442:~# ping6 -f -c 1000 -n fe80::ccbd:b358:925b:6fc9%wpan0
> PING fe80::ccbd:b358:925b:6fc9%wpan0(fe80::ccbd:b358:925b:6fc9%wpan0) 56 data bytes
>
> --- fe80::ccbd:b358:925b:6fc9%wpan0 ping statistics ---
> 1000 packets transmitted, 1000 received, 0% packet loss, time 115ms
> rtt min/avg/max/mdev = 13.431/17.535/87.919/7.599 ms, pipe 5, ipg/ewma 15.115/15.839 ms

7.599ms jitter. Now, if you nodes are not directly reachable, you'll
have to wait for each intermediate node to receive the packet in
flight, then re-transmit it. So maybe multiply that ~7.6ms jitter by 3
for each hop.

A lot will depend on how much audio is stored in a "frame" of audio
CODEC data. Some work on 20ms or 40ms frames; you might just get away
with it at 20ms, or maybe it'll chop up and you'll need to do some buffering.

This assumes that all the packets go via a single route, they may not
if there's multiple nodes that decide to route a packet. I think
real-time low-latency streaming will struggle beyond trivial cases.

The real question is, what sort of "voice traffic"? We talking someone
recording a voice mail via a doorbell and having that delivered to a
user's phone? A half-duplex hand-held transceiver work-alike? Live
full-duplex Voice-over-Thread voice chat?

I think that is an important factor here.

[nate mail]

Hi Stuart,

Thank you very much for your kind response.

I fully agree that audio codec algorithms are not the barrier for now to transmitting the voice packets over the mesh network, hence 250 kbps at 2.4G channels is probably satisfied the minimum requirements (your first reply).

I also agree that If the delay is not a critical issue, a certain amount of buffer will help for storing and playback voice packets (your second reply), assuming a simplex scenario, in which only one node is allowed to send voice packets.

I just roughly google the VoIP tolerance parameters, and a simple result is "VoIP calls must have a maximum jitter of 30 ms along with 100 Kbps of bandwidth for optimal call quality.". Assuming these parameters are acceptable, I think it is worth giving a try and see how it goes

Thank you very much again.

P

[Stuart Longland]

On Mon, 20 Sep 2021 09:33:49 +0100
nate mail <gusert...@gmail.com> wrote:

> I just roughly google the VoIP tolerance parameters, and a simple result is
> "VoIP calls must have a maximum jitter of 30 ms along with 100 Kbps of
> bandwidth for optimal call quality.". Assuming these parameters are
> acceptable, I think it is worth giving a try and see how it goes

100kbps … good luck with that! As I say, I was reading the "Performant
TCP for Low-Power Wireless Networks" paper
(https://www.usenix.org/conference/nsdi20/presentation/kumar) discussed
earlier on this list, and in that, they did do some measurements where
they measured throughput.

I think their peak was about 75kbps. That fell to 20kbps when a few
hops were introduced. On a good day.