> 4G definitions are still largely being fought over

In which world (other than T-Mobile US) does 4G mean anything other than LTE Advanced? Sure, there was a fight for many years but it was because of carrier marketing, not because of real technical grounds.

At least on a basic level I am quite interested in what comes out of the 5G efforts because what's being discussed will be very interesting for new use cases that cannot be done on existing networks.

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 expensive FPGAs. Besides that there is WiGig coming and you can offload traffic from LTE to Wifi - investing in those mm wave small cells seems rather pointless.

Beside that you can get those multi-Gbps with new Rel13 LTE carrier aggregation (up 32 CC).

It is possible to do compliant LTE phy on x86, of course it is not so energy efficient. Also x86 + fpga SoC is coming soon and could be interesting for that kind of purpose. Though I don't think baseband virtualisation will be something big in the near future.

And LTE CC is not the necessarily a good way to get multi-Gbps due to radio complexity.

I have seen such projects - real LTE PHY algorithms are much more complex than stuff in 3GPP. You can write something 3GPP compliant in some simplified cases, but it would be totally useless in real network.

Secondly you don't really want to use FPGA for majority DSP processing in LTE PHY. Design cycles on FPGA are too slow and HLS techniques are still not trusted. Beside that x86+fpga are some kind of specialized stuff - you could just put a PCIe accelerator with some major wireless SoC.

Modern x86 is quite competent as DSP using AVX. I think you are exaggerating. I have worked with LTE baseband as well, but admittedly never done an x86 LTE PHY. pCell claims to be doing quite complex network mimo LTE stuff on x86, still mostly vaporware though.

Regarding FPGA, of course you don't do the complete implementation in it, you accelerate the low level stuff, FFTs, coding, etc, as are already done in all baseband dsps.

Yep, AVX is nice, but still it is far from current DSP chips. I ported a subset of PHY to real AVX2 CPU and AVX512 sim. It is (sometimes) comparable to c6x (which is a crap DSP) if you take (much) higher clock into account, but comparing to current DSP IP cores it is a joke.

> 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).

HARQ loop in LTE is tight = 3 ms(3ms for ENB, 3ms for UE, 2 ms for air/RRH = 8 ms in total). It means that in those 3 ms you need to decode ack nacks in PHY, run scheduling and then send the data on other side of PHY.

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 ;-)

> HARQ loop in LTE is tight = 3 ms(3ms for ENB, 3ms for UE

Not sven sure how this is relevant. First of all the virtualization happens not on a global scale but quite local to whatever you can the base station in technical terms. Secondly there is no requirement in futuure standards to be as strict as LLE on that level. Lastly this is a few years out and obviously specialized hardware would be in place. It's kinda pointless to assume that this has to run on general purpose hardware.

Where does this idea come from that this virtualization has to happen on the other side of the world?

Future standards will be even more tight, 5G working assumption is 1 ms HARQ loop.

Where you got the idea that I assume the ENB has to be on other side of the world ?

> Future standards will be even more tight, 5G working assumption is 1 ms HARQ loop.

That's just to the base station, no? How does that in any way apply to what you transmit over your network?

> Where you got the idea that I assume the ENB has to be on other side of the world ?

Because your comment about latency implied that.

>That's just to the base station, no? How does that in any way apply to what you transmit over your network? We are talking about ENB here, core LTE network is already virtualized.

>Because your comment about latency implied that. Goal with ENB virtualization is to have single or few server farms per city, unlike today where ENBs are spread all over the city, and such usecase is still problematic with latencies - been there, done that.

>They're trying to come up with sub specifications to encompass more types of network use cases rather than thinking "xG is for cellular phones" it'll be more like 5Gx is spectrum/protocol for home internet, 5Gy is the spectrum/protocol the phone uses. Although from a marketing prospective this will sound like "Bring 5G to your home."

Intermingling the data and transport layers initially strikes me as a bad thing. What am I missing?

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 impenetrable to me despite the several dozen times I've read the definitions.)

    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 two network connected devices (interfaces) in a best-effort way.

What the transport layer adds on top of that is

- multiplexing of network layer addresses (TCP and UDP use port numbers for this) so multiple processes can share a single network layer connection and

- error detection/correction (TCP only) to transform the unreliable (best effort) service the network layer offers into a reliable service.

- Streaming (TCP only): the sender's data stream that a TCP client creates is split into packets and later reassembled.

I think it's a beautiful separation of concerns.

To add what Jerf said, the edit to my original comment says:

>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.

That's still the beautiful model you're referencing, not the reality of networking. If you saw what the actual network devices in the stack were doing, you would be... less impressed by the beauty, let's say. But they work, and they're fast. That has beauty of its own.

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.

     If you saw what 

In a nutshell, what are networking devices doing that mixes network and transport services (other than NATing)?

I imagine supporting signaling in motion and with limited battery and heat budget has a very different profile than at a fixed point with task-specific hardware.