5G?


Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,485
This may be jumping the gun a little, but are there any thoughts about what to do when 5G mobile networks come out? I know it's going to be several years, but it's a good idea to think about it early, rather than late. Hopefully a mainboard revision will be easier than a CPU board one?
 
I hate marketing. Cell providers haven't even met the established standards for 4G... and they certainly won't hit 5G

I don't think many providers hit the theoretical maximum speed for even GPRS before 3G rolled out.

But yeah, 5G's still in the early standards phase as far as I can tell. Last I heard their proposal for the replacement for the easily hackable SS7 system that underpins at least 2-4G was taken apart by academics and it looks holier* than my un-darned sock pile.

* as in has more holes than, not in the sense of being closer to god.
 
* as in has more holes than, not in the sense of being closer to god.
arthole.gif
 
I would have preferred a plugable modem board like the cpu board, then there also would be no difference between the standard and mobile edition mainboard but i think its not possible due to space or other limitations.
When a usable 5G modem is available, you will need to buy a new mainboard which is cheaper than the cpu board i think.
 
Oh, OK. I guess it might be better to wait and see what happens and then ask again?

Not at all, i was just trying temper expectations. I believe 5G calls for 1GBps. In order to achieve that providers are using clever banding tactics, but the fastest i have seen theoretically is 500MBps.

It also seems like providers are looking to use wifi style short range/higher throughput freqs to move even more data, but those will only be in major areas and are likely to drop with people on the move going in and out of range.

As far as the Pyra, it almost seems more trouble than it is worth, as the modems have multiple antennas, much more power draw (think HTC Thunderbolt with the then new LTE), and all sorts of tinkering and simulations to make it work. If ED did go down that road, it would likely only be a mainboard revision.
 
Considering it would only work in cities, you may be right that it's just not worth doing. However if they eventually turn off 3G, we'll probably want to at least get a modem that supports VoLTE.
 
In my opinion, 5G is not viable on this device. According to the schematics, there's a USB 2.0 hub on the CPU board with three downstream ports. One of these is connected to the 4G modem (the other two are connected to the USB host ports). IIUC mobile data goes this route. There's simply not enough bandwidth. Additionally, The OMAP5 is not able to handle 1Gbps mobile data. In theory, with a new CPU board (for faster SoC) and a new mainboard (5G modem), if there was an additional USB 3.0 hub on the mainboard, the bandwidth problem could be solved without changing the spec of the CPU board connectors (to maintain compatibility). This would probably affect the existing USB 3.0 OTG port, as it would only function as a host port (and maybe charging), but this violates USB specifications. Changing external connectors requires modified or new set of moulds (expensive). And finally, Dr Nicolaus is going to have another thousand piece puzzle to solve, as PCB area is very scarce. :)

edit: Maybe a firmware upgrade of the existing modem could bring us VoLTE...
 
Last edited:
USB specs have never bothered us before; observe the USB2 host port on the Pandora that won't talk USB1.1. But yeah, thus far the Pyra shouldn't have any of those restrictions, other than what appears to be a USB3 type-A port judging by the colour acting only as USB2.

I'm relying on the theory that VoLTE runs on top of the packet network, so it more of a software problem than anything else. By my reading of it, it's based on SIP, and codecs that ffmpeg supports out of the box - the only question is the credentials needed to make it all work together.
 
USB specs have never bothered us before; observe the USB2 host port on the Pandora that won't talk USB1.1. But yeah, thus far the Pyra shouldn't have any of those restrictions, other than what appears to be a USB3 type-A port judging by the colour acting only as USB2.

True. I guess that's OK as long as the Certified USB logo is not used.

I'm relying on the theory that VoLTE runs on top of the packet network, so it more of a software problem than anything else. By my reading of it, it's based on SIP, and codecs that ffmpeg supports out of the box - the only question is the credentials needed to make it all work together.

It's sad that even if it's technically feasible, it's not likely to happen because of legal issues. VoLTE is part of the cellular network software stack, therefore its implementations need to be certified. Maybe this kind of software is better suited for the baseband processor. Additionally, I'm not sure about the security implications of having a VoLTE implementation running on the same application processor as your OS.

Preliminary PLS8 datasheet mentioning VoLTE from 2013: https://shop2.mc-technologies.net/_media/mct/products/datasheet_PLS8.pdf (VoLTE is not present in the 2017 version)
Developer forum thread about missing VoLTE from 2015: https://developer.gemalto.com/threads/pls8-dual-sim-volte
Taiwanese MiniPCIe module built with PLS8-E, datasheet claims optional VoLTE: www.computex.biz/PhotoPool2/201307/201307241704389882.pdf
 
There should be no security considerations so long as linux process separation is maintained. It'll need to open up IPC pipes to get audio in and out, but it shouldn't be impossible to secure those.

In fact I suspect parts of the VoLTE stack are actually running on the app processor in a lot of phones. It certainly used to be the case that the radio processor was very slow indeed, and never highly stressed so that it can respond to radio events quickly enough.
 
In fact I suspect parts of the VoLTE stack are actually running on the app processor in a lot of phones.

Do you mean parts like an audio codec or lower layer stuff such as UE side IMS functionality?

There should be no security considerations so long as linux process separation is maintained.

As making a VoLTE call inolves receiving data from an external source and processing it with software, in theory it is possible to attack it remotely. It seems even av codecs have remote vulns: https://www.debian.org/security/2013/dsa-2793
 
Those av codecs only run under user privs as far as I know. As long as you've not allowed that user to do too much, the best you can do is process audio in some undesired way or just crash the codec.

The VoLTE IMS seems to start with SIP if I'm remember my reading of it at all well. That could probably be run on the radio processor in most phones, but can be run on the app processor in something like the Pyra I would expect.
 
Correct. Sorry if I was not 100% clear, I meant that at some point in time these vulnerabilities were unknown to the public and unfixed, and I see no reason to believe that it is impossible to have such a bug in an arbitrary multimedia framework today.
 
Everything has these kind of bugs in them. Once upon a time it was rarely a problem because computers weren't very connected, but since broadband it's been much more profitable for hackers to find these bugs, and consequently more worthwhile for researchers to report these bugs and for the developers to fix them.

Since the probability is these kind of bugs are present in every computing device since about 1978, I see it as a positive thing these bugs are found, documented and fixed. These days, the researchers finding bugs tends to be quicker than the blackhat hackers in finding new holes (only national secret service people tend to be quicker, but also tend to be better at keeping their stuff secret than anyone else).

Debian runs multiple stable branches, and backports security fixes from their unstable branch to all currently supported branches. They have a team of people checking what needs to be patched, and then implementing it, which puts in a slightly better position than we were with the Pandora, where we only really had Notaz implementing patches to the OS and libs. We will need to do a dist-upgrade from Debian Stretch 9.x to whatever they end up calling 10.x when stretch reaches its eol, but on my personal systems I tend to use rolling release systems which expose me to bigger changes from day to day, but I don't experience many problems because of that.
 
but on my personal systems I tend to use rolling release systems which expose me to bigger changes from day to day, but I don't experience many problems because of that.
Nobody's going to stop you from editing your sources.list and swich to unstable (which is a rolling release) on your pyra :p
 
Back
Top