If 6G becomes just 5G+ we’ll have made a big mistake(spectrum.ieee.org)
spectrum.ieee.org
If 6G becomes just 5G+ we’ll have made a big mistake
https://spectrum.ieee.org/6g-semantic-communication
66 comments
If the link layer knows that the encrypted bits are actually transporting video, then an attacker might have an easier time decrypting the traffic.
Perhaps – but well-compressed video is hard to distinguish from noise. You should already be assuming the attacker knows that kind of thing; googlevideo.com doesn't serve much other than video, for example.
No. That's implying your hardware has knowledge of cultural or human constructs. Your ascribing a set of qualities to a hunk of silicon you darn well have no business doing. Besides which, say googlevideo.cim flubs the Domain renewal and I snap it up and start serving a Slackware mirror for instance. The Stack below the application layer should neither care nor assume anything other than "take this, send here" with maybe some wiggle room where I have the option to tell it "best effort is okay" or "make it reliable".
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.
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.
> No. That's implying your hardware has knowledge of cultural or human constructs.
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.
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.
I wish someone would use that data and actually price match amazon. I hate trying to buy non counterfeit items on the vendor site only to b find out that they are 20-30% more after after shipping. Usally I give up at that point out risk amazon counterfeit.
You know, I die a bit inside everytime I find something like this out.
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.
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.
This isn't true. Good encryption makes it impossible to derive the decryption key even if you have a large selection of the plaintext.
Otherwise, an attacker could decrypt web traffic, knowing that a lot of the data is ASCII text.
Otherwise, an attacker could decrypt web traffic, knowing that a lot of the data is ASCII text.
All encryption is good until it's not.
Homomorphic encryption could be of use here if there is meta data for the encrypted content, but I also don't see the direct benefit to let a low level transmitter manipulate contents.
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).
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).
What's the point of homomorphic encryption if you can still see how the behaviour changes? You might as well just make the desired behaviour public and don't bother with trying to somehow get something to read sensitive data and change its behaviours accordingly without leaking information about the data (which is not feasible, no matter how advanced your encryption).
You're talking about homomorphic encryption of metadata?
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.
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.
No, the metadata would not be encrypted, so that you know which operations would be sensible. Just homomorphic encryption to do these operations without the sender being able to decrypt the respective data. Don't have any particular use cases at hand though. Brightening an image without being able to decrypt it or something like that...?
I've been out of the industry for awhile, and skimmed through the article, and I don't know that either of the problems would occur. It really depends how the idea is turned into a specification, as approved by a standards body from industry.
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.
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.
> 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.
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.
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.
> 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).
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.
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.
The article explains that machine learning techniques would likely be used. The transmitter doesn’t have to know your content to recognize that a certain stream has been flowing from A to B within a certain bandwidth. It could also recognize dropouts or delays in such transmission and prioritize the data when it finally comes through. There’s nothing wrong with that.
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.
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.
Indeed, seems like a pretty clear cut violation of rfc1925 points 5) and 12):
(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.
(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.
I don’t see it to be the general premise of the article. If anything, Shannon’s original work from 1948 seems to lie at the heart of the premise.
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.
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.
Don't build content formats into communication tech. Imagine if tcp could only send text and gifs, or http only send html and images. Sure you could try to have 6G define everything all the way up, but why? Instead, understand how to decompose characteristics such as latency, or multicasting, detection and reporting of missing data, etc. and build those mechanisms. Have the content use those capabilities to send, receive, reconstruct whatever using their own evolving formats and algorithms.
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.
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.
No thank you. Just give me even more reliable and even faster transmission. I don't really want machines to make best effort guesses what is happening at the other end of the communication pipeline, because the connection is now so bad compared to previous technologies that it has to.
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.
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.
Right? If the video is lagging because there's not enough bandwidth, don't drop packets for me; let my video software choose a different bitrate. I don't want my ISP messing with my packets.
100%. If I want missing packets to be inferred, I'd rather it happen on hardware I control than otherwise.
Sometimes is just impossible (physical laws or limitations of the current technology).
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.
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.
This. My wish list:
* 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.
* 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 prefer wired connection and WIFI for the "last mile".
I think the article should be: "If 6G is centralized, we have failed again."
Add decentralized radio to phones now, or we will build our own phones: http://radiomesh.org
Add decentralized radio to phones now, or we will build our own phones: http://radiomesh.org
Why doesn't the radiomesh.org website have any real details?
mesh communications are a real thing and the recipies are common, a quick DDG and :
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_...
http://servalproject.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_...
http://servalproject.org/
> When the wireless industry deploys 6G networks around 2030, they hope to usher in an era in which everything, not just our phones, is sensed, connected, and intelligent.
And every tiny detail of everyone's life tracked in real time. What a horror.
And every tiny detail of everyone's life tracked in real time. What a horror.
Don't worry, in Germany you can't even financially afford to have full LTE download speeds without data cap on more than 1 or 2 personal phones so you can be sure nobody else will pay out of their arse to connect everything to 6G nobody can afford.
Is it really a horror? I personally don’t care.
It won't matter until you're banned from places and services for having low social credit score
People with low social credit score have it for a reason. Maybe you shouldn't be a jerk in life if you want to enjoy it.
You don't have to be a jerk to have low social credit score. There are many things which are obviously normal (like being gay) or even beneficial (like particular psychoactive substances or uncensored books) but are outlawed in certain countries.
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?
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?
Do you think the technocrats who rule over you have a high social credit score? NO. They gamed the system and will work to suppress upwards social mobility to protect their moat.
Yes. It is. That you haven't stumbled or accrued something you don't want someone else tapped into by default, doesn't mean it isn't a big deal. You don't know who is on the other side of that data vacuum, or whether their agenda paints a target on you or someone you love or not.
Give it time, and think about it.
Give it time, and think about it.
This is using strange terminology, but it sounds like 'layer B' and 'layer C' are literally higher layers in the network stack. Why would those things be locked in to '6G'? Why not use them with existing 5G hardware or on my home fiber connection?
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?
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?
What about coverage?
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.
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.
5G seems to me like planned obsolesence of 4G with only an incremental improvement. 4G was supposed to be "Long-Term Evolution". I had thought that meant forward- and backward-compatibility for decades. Granted, latency is much lower. Did I get taken by marketing?
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.
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.
I have a 5G handset. I keep it disabled. The rare speed up is not worth the battery cost.
>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.
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.
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.
The 4G core is derived from the one built for the GSM. Sure it was updated here and there but it still runs some piece of software from the 1990.
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.
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.
Just staying on 4G doesn't sell new phones.
5G doesn’t sell phones either. I don’t know anyone who cares about it whatsoever.
i care about it a lot.
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
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
Owning your own phone outright often solves this rent-to-own upgrade problem.
the thing is i did own it out right, ATT just decided no more of that phone you have to have what we give you
Consumers will pay the extra 100$ for the feature but it won’t make them buy new phones
I still have no idea what the hell LTE is or how it relates to 4G after trying to read up on it.
4G is much cheaper to deploy over a region than 5G since you don't need as many towers.
I keep seeing this repeated but I'm pretty sure this isn't true.
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.
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.
Because most people confuse 5G or True 5G = mmWave. It is actually quite tiring.
I don’t get the benefits of the articles vision of 6G. There is a good reason for why we use the OSI Mode and separate problems that appear at the physical layer from those that appear at the application layer. I think of it as a powerful and universal interface specification.
I couldn’t find a single argument in the article that even justifies mingling some general machine learning with the actual physical data transmission.
Please, 6G people, more bandwidth and lower latency is all we want.
The one thing we need is a legal agreement that company ee and service providers don’t water down the phrase “XG”. They use it as a marketing term rather than a technology. So the moment they start spending money on it and they want to sell it even if it’s not fully baked.
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.
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.
Almost all of 5G that has actually been deployed comes under the header of an evolution, over the long term, of what was called "Long Term Evolution" (LTE), before it was rebranded "4G" to make 5G look like a fundamentally new product. That includes an all-IP core network, full-duplex radios, IP voice, etc. All of that was in the LTE specs.
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.
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.
Impressive guest article.In my opinion there is huge telecom cold war and giants like China and S. Korea is more focused on just winning this battle rather than the quality of tech.
>At the University of Oulu in Finland, where I am a professor and head of the Intelligent Connectivity and Networks/Systems group, we’re working on a new research vision called VisionX.
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.
[1] https://export.arxiv.org/abs/2108.05681
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.
[1] https://export.arxiv.org/abs/2108.05681
All of this fanciful stuff is just at the wrong layer.
> "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.
> "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.
>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.
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...
https://en.wikipedia.org/wiki/Motion_compensation
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...
https://en.wikipedia.org/wiki/Motion_compensation
The most important application to consider when developing the next generation of wireless communications technology is to ensure that 6G will have the robustness and reliability needed to deliver on the promise of doubling Zuckerberg’s net worth by making his portable VR pr0n world into a reality. Users should be able to strap on a VR helmet anytime, anywhere and partake in Metaverse activities that far exceed the imagination of even the most crazed Roman emperors.
Actually delivering on that would be impressive. And I'm not a Facebook property user.
So just 6G, but add at the end of the specification "All data needs to be json encoded with a >>Semantic fingerprint<< tag."
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."
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."
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).