[NNagain] Verizon, T-Mobile, Nokia get noisy on network slicing and net neutrality (LightReading)

[Dick Roy]

  _____  

From: Robert McMahon [mailto:rjmcmahon at rjmcmahon.com] 
Sent: Saturday, March 9, 2024 12:58 PM
To: dickroy at alum.mit.edu; Dick Roy via Nnagain
Subject: Re: [NNagain] Verizon, T-Mobile, Nokia get noisy on network slicing
and net neutrality (LightReading)

 

 

What is DSRC?

[RR] Don't get me started! :-(:-(:-(  Very simply it is the optimal
technology for V2X comms (it is in over 11 billion devices on the planet
today . aka Wi-Fi at 5.9GHz . think 802.11a) that has been shelved here in
the US (temporarily if I have anything to say about it) in favor of an
8-year old technology that does not work and on which a single company has a
majority of the IPR.  Surprise, surprise, that company has invested 100's of
millions of dollars to execute this con job, and unfortunately it's working.
DSRC products were available more than 8 years ago and would have been on
the roads today (and in handsets) in large numbers saving lives, but that
wasn't good enough for that company because they stand to get >10x in
royalty fees if and when the FCC mandates their technology.  When the
general public becomes aware of this con, and fully understands the impact,
they should be and will be outraged! Think "DOWNFALL: The Case Against
Boeing"  . it's exactly the same thing . just the names have been changed.
Watch it if you haven't already!

Contact me if you want more details!  I am looking for any and ALL help I
can get to expose this fraud.

Cheers,

RR 





DSRC (Dedicated Short-Range Communications) is a wireless communication
technology that enables vehicles to communicate with each other and other
road users directly, without involving cellular or other infrastructure.
DSRC is based on WiFi technology




https://auto-talks.com/technology/dsrc-technology/#:~:text=What%20is%20DSRC%
3F,involving%20cellular%20or%20other%20infrastructure.

On Mar 9, 2024, at 12:42 PM, Dick Roy via Nnagain
<nnagain at lists.bufferbloat.net> wrote:

 

 

.

 

As expected this technique is designed to allow exactly what NN was designed
to prohibit (treating packets differentially in the internet based on
economic considerations*)... this is IMHO why instead of calling a spade a
spade mobile carriers avoid describing this in a useful way, as it is
exactly about prioritisation... IMHO that will back fire, and a better
avenue would be to be open about what it enables and propose a method to
restrict the potential issues. E.g. (I am making this up on the fly, so it
will likely not hold up to any degree of scrutiny) by self limiting to never
commit more than X% of a cell's capacity to slicing, IFF the cell is used
for normal end user service at all. So admit that there is some trade-off
here, limit the fall-out, and then describe why we as a society should
embrace that trade-off. I am a bit sceptical about the whole car 2 car
communication thing (that is cars talk to cars, not people n cars talk to
people on cars ;) ), but if a Carrier believes there is value in that for
e.g. accident avoidance, then tell how this requires the stricter network
guarantees that (only?) slicing can deliver.

[RR] V2X communications for saving lives will NEVER go through ANY carrier's
network in spite of what you hear.  There is simply no way anyone is going
to pay to have BSMs broadcast 10 times a second to prevent accidents, and NO
CARRIER is going to give that capacity away for free, even if they had
enough to carry the traffic, which they do not by many orders of
magnitude!!!  More importantly, the information being exchanged does NOT
require a network to get where it needs to go!  The 5G hype you hear from
various carriers and equipment suppliers related to V2X communications is
all powerpoint BS (to make shareholders happy). And there is a ton of it out
there! :-):-)

 

RR






  _____  






Nnagain mailing list


Nnagain at lists.bufferbloat.net


https://lists.bufferbloat.net/listinfo/nnagain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20240309/c118ba27/attachment.html>