51–60 of 77 posts
It seems like it will just mean you can hit your data cap faster.
Agreed. I've got 4G at the moment and it's plenty fast, since I can only use it for moderate surfing/etc since I'd otherwise hit my monthly cap in a week. If I had super fast 5G, I could accidentally burn through my cap in a day.
Earlier quoted context omitted.
That the data and transport layers are almost always intermingled, because the "OSI network model" you were taught about in school is basically a lie. (At least inasmuch as it is claimed to describe anything in the real world. As a source of vocabulary, it's at least OK, though it does suffer from people using numbers where I would rather they used the names of the layers. Much like RAID terminology is still impenetr…
data and transport layers are almost always intermingled In what sense other than NATing, which has been a stop-gap measure to deal with IPv4 address shortage? TCP/UDP sit on top of the network layer, not the data (link) layer. And the two main requirements that TCP/UDP make of the network layer is (1) that all network layer connected devices (interfaces) have a unique address and (2) you can send packets between any…
And I mean real network hardware through which the packets your received these words are, too, not just abstract theoretical "somebody's got something somewhere that does something weird". The model hasn't been accurate since before it was created.
Earlier quoted context omitted.
Curious - which town are you in? I have 4g and 200mbs-1 fttp and I live in a field in the middle of suffolk.
Even in some parts of Cambridge 3/4G leaves a lot to be desired. EE has sometimes downtimes that can be measured in days. Its very disappointing. Its also absurd companies offering "unlimited" mobile traffic do deep packet inspection. Whenever I try to SSH to any of my servers I get banned immediately, despite having a ridiculously low data rate.
Indeed, ToS requests that you don't use the data connection for something like VoIP or other type of communication, in practice they don't care.
I have in Germany's Vodafone 3GBs that I can spend over LTE, and boy, they are spent religiosly until the last KB. Half free communications to outside Germany, half is streaming music/videos.
> With 5G, downloading feature-length movies could take less than five seconds. With 4G, downloading feature-length movies could take as long as eight minutes. But will it move everybody back to download versus streaming. Be interested to know how much of streaming start time is network time to first byte versus authenticate/authorise/check geo-fence admin activities? So would be slightly faster start time and may be…
Each day that goes by will make streaming operators care less. A gigabyte costs a fraction of a penny to transmit at current IP transit prices.
Personally, I'm just hoping that 3G will eventually make it to England. That seems more realistic, though I don't doubt that the Bay Area will be happily basking in this 5G niceness by the time it happens. I just got back from 3 months in Southeast Asia, and it's just baffling to me how I could get fast data to my phone in virtually unlimited quantities, out in the sticks of rural Cambodia, for five dollars. But comi…
> Driverless cars with extremely fast response times Seems like relying on low network latency for critical safety features is designing a fundamentally flawed system. Is this really how driverless cars are being made or is the author just pulling things from his ass
Surely it's the latter. Driverless cars that rely on Internet access would not be feasible, for obvious reasons. Driverless cars will likely eventually communicate via some peer-to-peer wireless technology, but I would assume that would use a different set of protocols than our mobile phones do.
> Driverless cars with extremely fast response times Seems like relying on low network latency for critical safety features is designing a fundamentally flawed system. Is this really how driverless cars are being made or is the author just pulling things from his ass
Driverless cars need detailed and up-to-date map information. After you enter a destination it will need to download and/or update that information. It wouldn't be a safety issue, though. The car would not start driving to the destination until it had everything it needed.
4G definitions are still largely being fought over, and you're gonna try and jam "5G" down my throat? The entire article is complete speculation, and the sad part is that they don't even talk about the cooler ideas they're coming up with for the specification. For anyone wondering about 5G I think the coolest thing they've discussed so far is breaking down the different use cases (people in home, people traveling on…
This is totally wishful thinking. No one in industry has a slightest idea what 5G will be. We keep throwing fancy terms like eNodeB virtualization and then we have a reality check - LTE userplane cannot be virtualized due latency and performance reasons (LTE PHY on x86 - yeah, right...). Same goes to those mm waves with beamforming - no DSP (IP core) can handle it now and even soon. You need to stick with very expens…
And LTE CC is not the necessarily a good way to get multi-Gbps due to radio complexity.
Earlier quoted context omitted.
This is totally wishful thinking. No one in industry has a slightest idea what 5G will be. We keep throwing fancy terms like eNodeB virtualization and then we have a reality check - LTE userplane cannot be virtualized due latency and performance reasons (LTE PHY on x86 - yeah, right...). Same goes to those mm waves with beamforming - no DSP (IP core) can handle it now and even soon. You need to stick with very expens…
> LTE userplane cannot be virtualized due latency and performance reasons Care to elaborate? I fail to see what the technical challenges are. Many services are already virtualized just on different layers if I understand this correctly (for instance Wifi calling).
LTE PHY requires a lot of algorithms that doesn't fit well on x86 or general purpose HW like FFT or turbo decoding. Those usually are done in HW accelerators of baseband SOCs. x86 lacks also complex arithmetic ISA, where wireless DSP do many complex multiplies in on cycle and complex ops are ~80% of signal processing done on DSP (not accelerators).
Second things is energy consumption, take e.g. Ceva XC4500 DSP core and a equivalent Xeon - it is magnitudes more efficient. In case of FFT or turbo it gets even worse.
Lastly, IQ data streams requires a lot of bandwidth ~1Gbps per one carrier in case of 20MHz. FDD LTE uses mostly 2 or 4 antennas in each direction, where TDD is good with 8 antennas, and this just one cell(sector). Newest ENB can handle up to 96 cells (with 2 antennas) in one box.
In theory you could run non-PHY layers of uplane in a server and use ENB as a L1 server, but still the lower MAC and scheduler needs tight latencies so server with DPDK is a must, but ARM/PowerPC/MIPS parts of the basebands SoCs are left idle (not really useful for PHY). PDCP layer seems reasonable to run in SDN because of carrier aggregation and not so tight latency requirements, but this layer is very simple.
Of course you can run whole control plane in a cloud, which actually makes sense but this is not a great achievement ;-)
Earlier quoted context omitted.
That the data and transport layers are almost always intermingled, because the "OSI network model" you were taught about in school is basically a lie. (At least inasmuch as it is claimed to describe anything in the real world. As a source of vocabulary, it's at least OK, though it does suffer from people using numbers where I would rather they used the names of the layers. Much like RAID terminology is still impenetr…
data and transport layers are almost always intermingled In what sense other than NATing, which has been a stop-gap measure to deal with IPv4 address shortage? TCP/UDP sit on top of the network layer, not the data (link) layer. And the two main requirements that TCP/UDP make of the network layer is (1) that all network layer connected devices (interfaces) have a unique address and (2) you can send packets between any…
>On a small note, this is "finalized" pdf but in reality it will change when implementation occurs.
It's one thing to say, here's the specification, however like construction you get to the site and then you realize oh shit, this isn't going to work. So they amend changes to make it work.
In a perfect world they should have gone back to the engineers/architects and reported their findings so they can make the changes to the white paper accordingly. But this almost never happens, same thing in the tech industry.
That's why when they go back on site to fix a pipe leak they drill into the electrical conduit because they moved the whole line to the right 3 feet and never told anyone.