If 6G becomes just 5G+ we’ll have made a big mistake
spectrum.ieee.org
spectrum.ieee.org
Problem 1: So much for the OSI model. You're putting application-level knowledge in the link layer. Ugh. Not that it's entirely unprecedented, but there are reasons the layers are separated: heterogenous apps need to work together on heterogenous hardware stacks that have radically different lifecycles. The coordination problem of just rolling out IPv6 has been hard enough, and is simple by comparison.
Problem 2: I don't actually want the transmitter to know much about what it's transmitting. I want encryption. This doesn't kill the deal, but it does make it a lot harder, and it means you definitely 100% need explicit protocol-level support for all of the semantics (and can't just throw deep packet inspection at the problem to solve any of it).
Anything else is biasing certain uses for certain endpoints, which strikes me as digital fiefdom carving. No thanks. Dumb pipes, generously provisioned, thank you very much.
Once upon a time I was working at a startup which pivoted slightly from generic "store analytics" to a product which mirrored the wifi network's uplink to a server where we would do deep packet inspection and watch you price-compare on Amazon (at the time, checkout was encrypted, but browsing and Add to Cart were unencrypted, and Amazon was offering discounts for price-comparing in store.) It was alluded to in the wifi network privacy policy that you didn't read. I understand that, in the days since I got creeped out and left, several hardware vendors have since added support in their equipment to facilitate the operation of these analytics.
We are fortunate that so much more is encrypted today, but pay heed! You must assume that hardware participates in a system that knows about human constructs, in all the most adversarial ways possible.
This is why we can't have nice things.
However... This is still markedly different than baking in heuristic, application specific optimizations into the hardware transport and lower levels. At that point, who sends what where should be a foregone conclusion. No hardware manufacturer should even be thinking of accommodating this niche case or that. I mean, they are free to, but everything I've seen says that isn't the best idea.
Leave it to the Application layer to optimize.
Otherwise, an attacker could decrypt web traffic, knowing that a lot of the data is ASCII text.
Deep packet inspection is still a security flaw in my opinion. For me it destroyed the chain of trust. I know that practical application to inspect the next trojan an employee downloads through https, but I believe interception should be done after the download (before anything is executed of course).
If so, I'm not sure I get it. If the infrastructure has to make prioritization decisions for certain types of traffic, I think it just needs to know the type of traffic. If it's "encrypted", but has an obvious end target of the computation, than it's not really encrypted.
The way QoS works for VoLTE for example, is not by putting application layer knowledge at the link layer. Instead the services that activate and route a phone call, have the ability to send a rule, called a traffic flow template, to the underlying LTE network. The flow template is a description of a flow from/to the device, that then has the transport network apply the expected scheduling behavior. I want a guaranteed 15 kbps for real-time voice, the LTE network can then use to coordinate radio scheduling, prioritize against background bulk transfers, block handoffs to cell towers that wouldn't have enough capacity, etc.
In concept this would work with fully end to end encrypted video and chat (I left the industry before the encrypted side was rolled out). I suspect some might argue the flow template itself leaks information about the data, but an observer of the network traffic can likely glean similar information, a steady flow of small packets is probably voice traffic type of idea. This just gives the network enough information to identify a flow and control for how to schedule the packets.
The biggest restriction is rollout and integrating with external services. Needs agreements between companies, restrictions on abuse, etc, etc.
Anyways, I don't think what is being proposed necessitates the problems. It'll really depend on what the standards bodies decides to do.
So you need to put link-layer knowledge in the application layer, and on anything in between the app and the network link. Your app needs some API to do this, and it surely isn't a transparent connect(2). And if you want full support, then when hook up your LTE access point to a consumer-grade wifi-router — or maybe your business's router, as a backup if the primary link fails — you'll need some way to relay support there as well, and to your desktop software running Windows, and to OSX and Linux, and your Docker container.
It's all doable, it's just a massive amount of coordination in exactly the way "throw me some packets!" isn't.
Well let's not lose sight of the problem being solved here. If I'm a phone operator, I don't want someone downloading bittorrent on the same cell to cause packet loss and garble my phone call so it's unusable. Throwing some packets over the fence doesn't tend to work so well when there are constraints on the magic tubes.
Or more simply, the sender could request a specific traffic bandwidth or pattern as part of initiating the connection.
The OSI model isn’t a hard requirement. We already have things like QoS which are commonly used to prioritize traffic.
(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Problem 1: OSI leads to a lot of energy inefficiency. It was formulated in a world where networks were small and climate change was not a major concern. Cross-layer protocol/tech can and should be more easily deployable. The common issue with this and IPv6 is the inability to deploy new stuff on an incremental basis without breaking its core connectivity functionality.
Problem 2: Again, I think the article does not specifically call for this. This could be _a_ way to do this. One could do other things that are a cooperation between tx and rx which would also convey the meaning to rx effectively.
The rest can be done by software / hardware on top of that, if one wishes so, I don't see why that has to be integrated into the communication pipeline itself.
* Shorter delays for voice traffic, closer to the copper wire experience from 30 years old. At least for local calls.
* Better voice quality throughout. We have great codecs and lots of bandwidth, we can talk at hi-fi quality.
I'm fine with the speeds 4G gives me.
I can't have 40 ms ping time with a game server on the other side of the world no matter what and my 4G connection slows down when it snows. Ok, I should pay somebody a relatively huge sum to lay a fiber optic cable to my home :-)
An AI to fill in the blank of a video call (degenerate case: a still picture) is OK for me. Sending me a summary instead of a book, a trailer instead of a movie does not.
By the way, AIs were filling in the blank of video calls when bandwidth got low in a Fire upon the Deep. The calls were between far away spaceships, probably very superluminal transmissions because of how physics work in that book.
With 6G deployment already being projected, when I don't even know anybody with a 5G handset, it also seems like a make-work technology.
Deployment of a new wireless technology throughout a national wireless carrier, let alone all carriers in a country the size of the US, or in the world, is such a huge undertaking in terms of environmental resources, that it seems almost irresponsible unless there is a significant improvement.
2G was a quantum leap over 1G analog networks. In 2G networks like GSM, the digital communications stack was so tightly integrated, and as optimized as a 1990s video game, that even everyday layman users knew stories like "I could send an emergency SMS from the middle of nowhere even when there was no signal". It seems like that kind of robustness is missing the more abstract and higher-level these wireless generations go.
my phone worked fine, reliably and im not in an area where bandwidth is a problem
yet ATT deactivated my phone shipped out a "new better model"
i get a 5G googlized flipphone from them, thats not all.
i get about 2 and ahalf or three bars reception at best, my phone now drops connections, and drops network, and i only have to charge it twice a day
5G brings obvious improvements, just ask the airline industry, they have some things to say as well
The 5G protocol also runs on the same frequencies as 4G, but with slightly improved range and bandwidth.
5G mmWave (or whatever it's called) is the 60Ghz very short range version with way higher bandwidth.
Well you can bet there will be at least 200M 5G iPhone by the end of next year. That is iPhone 12+. By 2023 the should be 1.5B 5G Smartphones.
5G is pretty damn good in many ways and solve most of the teething problems in 4G. Especially in densely populated areas. Not entirely sure about 6G though.
Whereas with the 5G, the core was redone from scratch: everything is a micro-service, a service mesh for discovery and subscription, etc ... . This base will be kept for ~30 years. So the 6G is going to be a "simple" extension of the 5G.
And every tiny detail of everyone's life tracked in real time. What a horror.
Did you know having smoked some weed in Arizona (where it is legal), which you could have done even for a scientifically-backed medical purpose, automatically makes you a criminal in South Korea and you will be thrown in a prison if you then travel to there and their officials find out, even if you are not their citizen and have done the "crime" years ago and fairly far from their soil?
Give it time, and think about it.
> "making it possible for a device to infer missing video data based on context clues"
Great, can't wait for your video streaming app with AI inference
> reduce the bandwidth, data rates, and energy consumption required for transmitting data
OK, love to see your work on the compression standard that's going to be used in this codec you're designing, sounds great.
This all sounds great. Stick it in your application.
But it's nothing whatsoever to do with the network layer, which is going to continue to benefit from lower latency, lower overhead and higher bandwidth.
If you happen to live in a place where cell carriers choose not to cover (E.g. go 200 miles west from the east coast) and you are stuck with a landline you’ll find a scarlet letter that says ‘PROBABLE SPAM CALL’ on the CallerID of anybody you call.
This is unacceptable. The last G is fiber optics and it is about time.
This pretty much sums up the narrative and incentive of the article. The paper [1] is linked in the article, but for included here for those who might want to take a look at it.
There is nothing wrong with so called dumb pipe other than the name. Because networks in 21st century is anything but dumb. That is especially true in Wireless / 5G network. Both semantic and efficiency is fundamentally tied to another factor known as cost and QoS (I dont see how that Semantics is any different to QoS ). Which 6G development are well aware of. And network vendors are already complaining about the complexity of 5G.
I still remember there was some debate in ~2019 that they should try and simplify everything in 6G. And unless there are some killer apps requirement, i think 4G / 5G transition will be the point where it hit the end of S curve, being good enough for 80% of people. As a matter of fact, I know a lot of people are already happy with their 4G. They just want cheaper 4G, not faster and more expensive 5G. In terms of cost per Data usage 5G will provide exactly that, but it is sort of counter intuitive for most consumer that 5G is actually cheaper. Nor will MNO price them as such.
So this is called interpolation, and it has probably been set to "enabled" inside the video menu of your HDTV for a decade. Prediction is also part of the video compression standard:
https://en.wikipedia.org/wiki/Video_compression_picture_type...
https://en.wikipedia.org/wiki/Motion_interpolation
https://en.wikipedia.org/wiki/Interpolation_(computer_graphi...
What's really different in 5G was, predictably, difficult and expensive to deploy, and it remains very challenging. On top of that, it is much more complex to operate in a way that extracts the most advantage from things like beam steering, while avoiding pitfalls like poor penetration of mmwave bands into buildings, or even cars.
Until what's called 5G Stand Alone (SA) is mastered and widely built-out, it is difficult to say what is buildable in 6G and what is a lab demo.
On top of that, it is difficult to find real world use cases that are uniquely enabled by even the most complete deployment of everything 5G claims to be able to do. If you have a 5G phone, what have you been able to do you can't do on a wifi network? It's just more bits. Which is nice. As an evolution of the network.
Consider the following paragraph:
>Including level B technologies would look something like each video call participant locally predicting and rendering any missing portions of the video data if a glitch or network hiccup happens. Currently, we allocate significant amounts of time, energy, and computational resources to ensure very high transmission reliability. But instead, each participant’s machine—whether it’s a laptop, phone, or something else—would “fill in the blanks” by inferring what was missing based on what had arrived. On a deeper level, machines would be able to reconstruct data with the same meaning as what was sent, even if it’s not the same on a bit-by-bit or pixel-by-pixel level. The machine learning techniques to do this already exist, though they are still relatively new: Two examples are variational autoencoders and generative adversarial networks. The latter in particular has gained attention in recent years because of its ability to develop deepfake images.
The author is talking about video codecs. Certainly codecs can be much improved based on a higher-level understanding of the content. What does that have to do with networks?
On top of that to mention the privacy/security issues if Huawei or whoever hardware vendor not only had the bits but also all the semantic information.
Add decentralized radio to phones now, or we will build our own phones: http://radiomesh.org
https://www.academia.edu/2487377/Making_a_mesh_router_gatewa...
https://www.ab9il.net/crypto/serval-project.html
https://www.researchgate.net/publication/220626953_Making_a_...
Other than that I don’t think we want semantic understanding of communication at the link layer. There is no positives there with the current state of security and privacy. Of course that could usher in new research in security and privacy preserving techniques and it could make for some interesting stuff.
I mean there may well be semantic network ideas beyond just QoS that are actually interesting, so far it's just that no semantic network proposal convinced me that the right problem description is "do the bit pushing really, really well."