I always wanted "wireless wires" that would look like two usb/ethernet/hdmi/etc dongles and just provide one or more connection types at a desired bandwidth, regardless of protocol. They'd be encrypted by a private key set by touching them together, or installing one file of random bytes and arbitrary size to each as a usb drive (either as a separate usb plug or a physical switch that enables storage mode).
So users could plug one into their computer and the other into a drive/router/television/etc and it would "just work" without having to fiddle with 802.11 setup friction. I wonder if DECT-2020 New Radio (NR) could be used for this?
I wanted to invent this in the early 2000s when I first saw wireless usb over wifi and thought "well that's terrible", akin to the disbelief I felt in the '90s when I saw that usb connectors were flat instead of circular and couldn't believe that someone would come up with something so ridiculously annoying. But after 20 years of something so obvious not being invented (probably due to monopoly/regulatory effects), along with the hundreds of other things I wanted to invent in another life, I can comfortably release this idea into the public domain.
The bandwidth of DECT-2020 NR is 80 Mbps. It wouldn't be useful for any of those except for USB2. HDMI is high enough bandwidth that it can't be done over Wifi and needs to use 60GHz radios. What would be useful is light-based networkig, Lifi, which can do Gbps within one room.
One problem with "everything" radio dongles is that different protocols have different requirements. In particular, how they handle errors and latency. Ethernet doesn't retry but could handle latency from low-level or high-level retries. Wifi does retries cause it works better than IP level. HDMI is streaming with errors or latency from errors causing visible artifacts.
This TV station guy packs 4K video transmission on 18 Mbps RF channel [1].
Mind you most of networking high bandwidth real-time transfer and processing is just another low bandwidth batch processing accumulation.
Personally I am working on a new robust and low latency wireless PHY based on polarization that can work even with non line of sight (NLoS) that perhaps can do away with retries, but we shall see.
[1]TV Station Launches Multiple 4K Broadcasts OTA on ATSC 1.0 [video]:
These are kind of two different things though. The challenges of encapsulating a wire protocol to display video like HDMI and using a protocol like ATSC 1.0, which has support for subchannels that send effectively arbitrary bitstreams that in the case you linked, happens to be fragmented h.264/h.265 that the TV already has codec support for. 80 mbit for sub-ms latency, lossless encoded HDMI is a non-starter. 80 mbit for sub-200ms lossy encoded video streams? Yeah, let do 100.
There's an alternative like UWB in RF that caters for more bandwidth if needed but come with low power requirement across the wide bandwidth [1]. Or the the FCC/OFCOM/etc need to bite the bullet and provide huge chunk of RF spectrum for this next generation wireless peripheral standard that's comparable to USB 4. Together with the latest offering direct RF ADC/DAC and RFSoC it is just a matter of time for this realization [2],[3].
I believe the issues lamented by the grand parent comment is resolvable even in RF spectrum and the required speed will be achievable in the near future, stay tuned.
Well maybe "fiberless fiber optics" where each end would have a plugin for an arbitrary length of fiber optic cable, normally about 10 feet long, that would run up to the ceiling and optionally exit a lens to talk to the other end through open air, with maybe a range of 100+ meters or something. If someone could make one for under $100 that could handle 10K HDMI/100 Gbps, I'd buy it. Ideally with radio fallback on something like NR for partial functionality if the view gets blocked. I want something that "just works".
Thinking about this further, I'd like to see a resilient fiber optic standard with a 180 or 360 degree fisheye lens where bandwidth falls off by angle of alignment. So light bouncing off the walls might give 1 Mb/sec, but direct line of sight would give Gbps to Tbps speed.
It's 2024 for crying out loud. I'd like to see some of these trillion dollar tech companies actually innovate for once instead of milking decades-old technologies and sucking up all the available capital to keep us delivering fast food instead of inventing this stuff in our parents' basement like in the late 1900s when people had any leisure time or disposable income at all.
I have a couple of these in hand. What they don't tell you there is you need to sign an NDA to get the most modern DECT versions of the software, because "it is still in development". I'm waiting for that signature now.
Also you have to dig through the data sheet to find out that the GNSS only works with LTE. If you want to use DECT GNSS can't be used, because it is part of LTE. Can't do both DECT and LTE at the same time.
For a standard published 4 years ago, I'm surprised my googling isn't showing up any reference boards or the like that would attract wannabe hobbyists like myself. Is there some fundamental problem why it doesn't seem to have made it to market?
How many companies are there that actually implement 5G, as opposed to buying a chipset from those that do?
Hardly surprising that this capability is slow to trickle down from the huge market of cellular to reuse of protocol concepts in the local wireless niche. It's one thing to select a gaint for riding on the shoulder of, another to actually do the climbing.
> How many companies are there that actually implement 5G, as opposed to buying a chipset from those that do?
The number of companies actually building stuff is far eclipsed by the number of companies amassing IP hoards around the tech.
Modern standards are an absolute tarpit; total waste of time to drive your career into that nonsense IMO. It's cool tech, but good luck with that -- you cant even start to build anything or use it without an army of lawyers and bankers clearing the path.
Anyone here feeling qualified to answer the question in the title?
The article describes various aspects, such as that the new DECT version uses modulation and other mechanisms also present in cellular NR/5G, which sounds like a big step forward but, at the same time, no difference in user experience either. The networks get more secure and efficient by the sound of this vendor publication, but is there any user-visible chance? Or are the under-the-hood changes "a big deal" as they put it?
Latency is probably the crucial specification here. LTE includes low latency IoT modes, but last I heard getting them to work was an active area of research. Maybe DECT-2020 is the plan B?
I suspect the big deal is combination of range, density, and effective bandwidth for given density, which is explicitly something they compare against other IoT wireless protocols.
> The simple answer is that although it's early days for DECT-2020 NR, it promises to fill a genuine 'gap' in the wireless IoT market for massive machine-type communication. An area where failure is not an option and could put at risk automation processes, critical infrastructure, livelihoods, if not lives themselves.
With regards to reliability, Wifi 8 seems have been dubbed "Ultra High Reliability" (UHR), as that will be its area of focus:
> This amendment defines modifications to both the IEEE Std 802.11 physical layer (PHY) and the IEEE Std 802.11 Medium Access Control (MAC). The amendment adds an Ultra High Reliability capability to a Wireless Local Area Network (WLAN). The Ultra High Reliability capability is defined for both an isolated Basic Service Set (BSS) and overlapping BSSs as:
> *At least one mode of operation capable of increasing throughput by 25%, as measured at the MAC data service Access Point, in at least one Signal to Interference and Noise Ratio (SINR) level (Rate-vs Range), compared to the Extremely High Throughput MAC/PHY operation, and
> *At least one mode of operation capable of reducing latency by 25% for the 95th percentile of the latency distribution compared to the Extremely High Throughput MAC/PHY operation and
> *At least one mode of operation capable of reducing MAC Protocol Data Unit (MPDU) loss by 25% compared to the Extremely High Throughput MAC/PHY operation for a given scenario, especially for transitions between BSSs.
> An area where failure is not an option and could put at risk automation processes, critical infrastructure, livelihoods, if not lives themselves.
Which is exactly 5G's sales pitch, which is designed for low latency and high reliability aimed at critical applications like factory automation, remote surgery, self-driving cars, etc. And there is currently a push for 5G private networks.
So it remains to be seen if this gets any traction.
The problem is that the 5G hype isnt telling the whole story. Yes, you certainly could drive high thruput across the radio access network, at low latency, and yes, thats exactly what you would need to do things like self driving cars. The problem is that the radio is just one tiny part of the whole communication chain, and for safety-critical things, the entire chain must be equally fast and robust.
That means, for example, that the chip inside the car/robot must detect failures in the transmission path incredibly quickly and switch to a secondary channel, that the radio controller can detect when the network (packet core) it thought it was talking to goes away, and recover, and that the packet core itself can detect failures in its components and fail over or restart. It has to do all this in the time it takes for a warehouse robot to crush a worker, or a car to hit a bollard. Did I mention that todays packet cores are built from kubernetes and prayers? This degree of safety simply isnt happening anytime soon.
Perversely, it might actually be safer to deploy an entirely private network under the control of an enterprise and take your lumps there as best you can, than rely on an operator's network being able to do what you want all the time.
The radio is just a small part of 5G. The whole system is designed for these use cases.
So yes, this requires upgrades to fully compliant packet cores, which is expensive and not really happening because there is actually no business case at the moment.
AFAICT the upside here is the same as the downside, and similar to LoRa: you get to have your own infrastructure, but you also pretty much have to have your own infrastructure.
Having your own infrastructure is not really a barrier if you look at WiFi.
I kinda expected mmwave 5G to become an in-office replacement for WiFi: Completely managed by the provider, plenty of spectrum available and seamless roaming to public 5G.
But it didn't take off at all and most mobiles no longer even include mmWave antennas here in Europe (think Samsung). Nor do laptops. It would have been pretty ideal for this kind of indoor usecase.
I think part of the reason is that companies still really prefer to run their own infra.
It isn't, except when it is, and WiFi is established already. Sure, for a big industrial IoT rollout, you'd have to set up dedicated networks anyway, so you can choose them on their peculiar merits. For consumer IoT, requiring an additional hub or regional infrastructure is a losing proposition. For consumer-like commercial/industrial IoT and similar connectivity, think Redbox kiosks or fishing license machines where sites will not put the machines on their WiFi network, you might not have a good case for replacing cellular with your own infrastructure.
Where DECT might be competitive would be applications like wireless utility meters - high densities of installations where your own infrastructure could be more practical than cellular.
mmWave doesn't cross walls very well, what's the point if you have to install infrastructure inside buildings anyway? Plus, indeed, companies really prefer to have their own stuff, also because of reliability (what if the 5G carrier has a problem? It's rare but can happen), and simplicity (why using a VPN that passes through a public network and goes back to the company network, adding dozens of ms of delay in the process, if you're anyway on-site?)
I was thinking the provider would install 5G access points inside the building yes. For this the limited penetration is a real benefit because it means you can place more access points without them interfering.
Of course the network would not use a VPN but MPLS or something.
> Of course the network would not use a VPN but MPLS or something.
So basically the company's devices are provisioned with specific (e)SIM cards that would make the traffic routed to the company's network by the telco directly? If I would be a network admin in a big company, I'm not sure I'd feel well with that, as the provisioning/management of SIM cards out of the company's control. It would also mean that a rogue employee of the telecom operator would be able to access the internal network of the company. Attack surface seems too big.
mmWave is way to finicky, where even a human body can block the signal.
What I saw a lot of buzz about a few years ago was 5G NR-U, where 5G was standardized to run on the ISM bands (same bands as WiFi) so you could basically set up your own 5G network just like Wi-Fi. I'm not sure what happened to that, my assumption is the 5G patents are just way too expensive to justify the hardware set it up ad hoc like that compared to WiFi. Whoever is developing DECT these days may be way more willing to lower prices since they don't have a bunch of telcos to gouge.
So I read the article and know their goal is different but I saw the headline and actually thought of Japan when I saw this since PHS was shutdown around the same time: https://en.wikipedia.org/wiki/Personal_Handy-phone_System (think DECT you could roam between base stations with)
> (think DECT you could roam between base stations with)
DECT does support roaming between base stations. Most DECT base stations are designed as standalone devices, but Yealink, Snom, and other vendors do offer multi-cell solutions scalable to hundreds of base stations and thousands of devices.
Hmm. The DECT-2020 technology faced challenges that hindered its widespread adoption and prevented it from taking off. One of the reasons for its limited success was the emergence of competing technologies like 5G, which gained more traction and investment, overshadowing DECT-2020.
I'm not too knowledgable in this space, so my main questions are what are the advantages of DECT-2020 NR over something like LoRA (which I understand has license problems), zigbee, or 802.11ah (which is rarer but has less of a license issue)?
Lora is different from the others, in that it is for low-data-long-range. All those others are to connect a device to a local network. Lora is to connect to a remote network.
DECT (which I last saw in devices that I was programming in 2005), zigbee and 802.11 are all local network mediums.
802.11ac maxes out at maybe 60-80m, zigbee maxes out at around 80m and DECT (last I used it) maxed out at maybe 100m.
In respect of 802.11ah, it's still under 1000m, outdoors, IIRC. Great for the use-case of covering your factory in sensors, not so for the use-cases that LoRa is intended for.
From the article: "think: a million devices per square kilometer".
Range of DECT-2020 NR+ is comparable to Bluetooth Low Energy Long Range, which is plenty for a lot of applications but not in the same class as LoRa. But it's much higher bandwidth than LoRa and purportedly has determistic low latency, at least sufficient for audio, and they're marketing it for mission-critical and safety-critical applications.
Interestingly DECT seems to be alive and kicking in some areas. In my circle DECT baby monitors are popular, because they people don't want them to be connected to the internet.
My work headset is DECT, I always buy callcenter-grade headsets. DECT allows me to wander around the house as much as I like or need to during calls - kitchen, bathroom, balcony, whatever - with high fidelity audio. Bluetooth and other wireless technologies are significantly limited in range.
We've already replaced the entire DECT infrastructure for WiFi phones with MS Teams in our company. Not nearly as reliable or functional but we make do with it.
How do they work in terms of reliability and user experience (including sound quality)? I never tried the kind of infrastructure you have, but my experience with wifi-based calling (we use the Jabber application from Cisco) is largely suboptimal (most calls have sound artifacts, from super-short "holes" as missing packets which are mostly inoffensive, to heavy issues like no sound for 500 ms, or artifacts due to heavy-compressing codecs).
Are those WiFi phones plugged into the wall or are they cordless? I believe the advantage of DECT is that the phones consume much less power compared to WiFi which makes sense if they're on battery. Many of the IP phone vendors use DECT instead of WiFi for this reason and they sell POE DECT transcievers.
It sounds like it's bring pivoted away from phones and towards IoT in places like factories, with a focus on being more reliable than WiFi in places where it really matters
The bands are still around and still being used (though much smaller in trhe US than elsewhere) The main difference between DECT and the more free for all 2.4/5G bands is that in DECT the protocols are specified and designed to coexist and work together (there's no choosing a wifi channel, DECT is smart and will spread out by itself, both in time and freq)
There has been only one major installation of DECT for public access: in early 1998 Telecom Italia launched a wide-area DECT network known as "Fido" after much regulatory delay, covering major cities in Italy. The service was promoted for only a few months and, having peaked at 142,000 subscribers, was shut down in 2001.
142K subscribers isn't quite your kitchen and den phone any more. :)
> DECT is a surprisingly complex and capable system
'99-'00 I worked on a Linux-based tablet where the first iteration used a DECT extension for data (DECT MMAP)... Wifi was not yet dominant enough to be the obvious winner.
Most importantly, not having to deal with BT software shittiness. BT is actually OK when it works but getting it to work and not stumbling on edge cases is the tricky bit, suggesting the RF side of it is sane and adequate but let down by terrible software.
BT wouldn’t be so bad if it was all abstracted away by a dongle that handled all the communication and presented itself to the OS as a dumb audio device.
So users could plug one into their computer and the other into a drive/router/television/etc and it would "just work" without having to fiddle with 802.11 setup friction. I wonder if DECT-2020 New Radio (NR) could be used for this?
I wanted to invent this in the early 2000s when I first saw wireless usb over wifi and thought "well that's terrible", akin to the disbelief I felt in the '90s when I saw that usb connectors were flat instead of circular and couldn't believe that someone would come up with something so ridiculously annoying. But after 20 years of something so obvious not being invented (probably due to monopoly/regulatory effects), along with the hundreds of other things I wanted to invent in another life, I can comfortably release this idea into the public domain.
One problem with "everything" radio dongles is that different protocols have different requirements. In particular, how they handle errors and latency. Ethernet doesn't retry but could handle latency from low-level or high-level retries. Wifi does retries cause it works better than IP level. HDMI is streaming with errors or latency from errors causing visible artifacts.
Mind you most of networking high bandwidth real-time transfer and processing is just another low bandwidth batch processing accumulation.
Personally I am working on a new robust and low latency wireless PHY based on polarization that can work even with non line of sight (NLoS) that perhaps can do away with retries, but we shall see.
[1]TV Station Launches Multiple 4K Broadcasts OTA on ATSC 1.0 [video]:
https://news.ycombinator.com/item?id=39727651
I believe the issues lamented by the grand parent comment is resolvable even in RF spectrum and the required speed will be achievable in the near future, stay tuned.
[1] Ultra-wideband:
https://en.wikipedia.org/wiki/Ultra-wideband
[2] 100Gbps RF Sample Offload for RFSoC Using GNU Radio and PYNQ:
https://news.ycombinator.com/item?id=38555555
[3] Analog Devices Apollo MxFE 0.5 to 55 GHz Ecosystem:
https://news.ycombinator.com/item?id=38458482
Well maybe "fiberless fiber optics" where each end would have a plugin for an arbitrary length of fiber optic cable, normally about 10 feet long, that would run up to the ceiling and optionally exit a lens to talk to the other end through open air, with maybe a range of 100+ meters or something. If someone could make one for under $100 that could handle 10K HDMI/100 Gbps, I'd buy it. Ideally with radio fallback on something like NR for partial functionality if the view gets blocked. I want something that "just works".
Thinking about this further, I'd like to see a resilient fiber optic standard with a 180 or 360 degree fisheye lens where bandwidth falls off by angle of alignment. So light bouncing off the walls might give 1 Mb/sec, but direct line of sight would give Gbps to Tbps speed.
It's 2024 for crying out loud. I'd like to see some of these trillion dollar tech companies actually innovate for once instead of milking decades-old technologies and sucking up all the available capital to keep us delivering fast food instead of inventing this stuff in our parents' basement like in the late 1900s when people had any leisure time or disposable income at all.
Also you have to dig through the data sheet to find out that the GNSS only works with LTE. If you want to use DECT GNSS can't be used, because it is part of LTE. Can't do both DECT and LTE at the same time.
Hardly surprising that this capability is slow to trickle down from the huge market of cellular to reuse of protocol concepts in the local wireless niche. It's one thing to select a gaint for riding on the shoulder of, another to actually do the climbing.
The number of companies actually building stuff is far eclipsed by the number of companies amassing IP hoards around the tech.
Modern standards are an absolute tarpit; total waste of time to drive your career into that nonsense IMO. It's cool tech, but good luck with that -- you cant even start to build anything or use it without an army of lawyers and bankers clearing the path.
The article describes various aspects, such as that the new DECT version uses modulation and other mechanisms also present in cellular NR/5G, which sounds like a big step forward but, at the same time, no difference in user experience either. The networks get more secure and efficient by the sound of this vendor publication, but is there any user-visible chance? Or are the under-the-hood changes "a big deal" as they put it?
Full standard looks to spread across ETSI TS 103 636 part 1 to 5 available here: https://www.etsi.org/committee/1394-dect
With regards to reliability, Wifi 8 seems have been dubbed "Ultra High Reliability" (UHR), as that will be its area of focus:
* https://en.wikipedia.org/wiki/IEEE_802.11bn
> This amendment defines modifications to both the IEEE Std 802.11 physical layer (PHY) and the IEEE Std 802.11 Medium Access Control (MAC). The amendment adds an Ultra High Reliability capability to a Wireless Local Area Network (WLAN). The Ultra High Reliability capability is defined for both an isolated Basic Service Set (BSS) and overlapping BSSs as:
> *At least one mode of operation capable of increasing throughput by 25%, as measured at the MAC data service Access Point, in at least one Signal to Interference and Noise Ratio (SINR) level (Rate-vs Range), compared to the Extremely High Throughput MAC/PHY operation, and
> *At least one mode of operation capable of reducing latency by 25% for the 95th percentile of the latency distribution compared to the Extremely High Throughput MAC/PHY operation and
> *At least one mode of operation capable of reducing MAC Protocol Data Unit (MPDU) loss by 25% compared to the Extremely High Throughput MAC/PHY operation for a given scenario, especially for transitions between BSSs.
* https://grouper.ieee.org/groups/802/11/Reports/tgbn_update.h...
* https://www.ieee802.org/11/Reports/802.11_Timelines.htm#TGbn
Which is exactly 5G's sales pitch, which is designed for low latency and high reliability aimed at critical applications like factory automation, remote surgery, self-driving cars, etc. And there is currently a push for 5G private networks.
So it remains to be seen if this gets any traction.
That means, for example, that the chip inside the car/robot must detect failures in the transmission path incredibly quickly and switch to a secondary channel, that the radio controller can detect when the network (packet core) it thought it was talking to goes away, and recover, and that the packet core itself can detect failures in its components and fail over or restart. It has to do all this in the time it takes for a warehouse robot to crush a worker, or a car to hit a bollard. Did I mention that todays packet cores are built from kubernetes and prayers? This degree of safety simply isnt happening anytime soon.
Perversely, it might actually be safer to deploy an entirely private network under the control of an enterprise and take your lumps there as best you can, than rely on an operator's network being able to do what you want all the time.
So yes, this requires upgrades to fully compliant packet cores, which is expensive and not really happening because there is actually no business case at the moment.
I kinda expected mmwave 5G to become an in-office replacement for WiFi: Completely managed by the provider, plenty of spectrum available and seamless roaming to public 5G.
But it didn't take off at all and most mobiles no longer even include mmWave antennas here in Europe (think Samsung). Nor do laptops. It would have been pretty ideal for this kind of indoor usecase.
I think part of the reason is that companies still really prefer to run their own infra.
Where DECT might be competitive would be applications like wireless utility meters - high densities of installations where your own infrastructure could be more practical than cellular.
Of course the network would not use a VPN but MPLS or something.
So basically the company's devices are provisioned with specific (e)SIM cards that would make the traffic routed to the company's network by the telco directly? If I would be a network admin in a big company, I'm not sure I'd feel well with that, as the provisioning/management of SIM cards out of the company's control. It would also mean that a rogue employee of the telecom operator would be able to access the internal network of the company. Attack surface seems too big.
And trusting the network is an old security model in this day and age (think Google beyondcorp). Trust should be on the endpoint not the network.
What I saw a lot of buzz about a few years ago was 5G NR-U, where 5G was standardized to run on the ISM bands (same bands as WiFi) so you could basically set up your own 5G network just like Wi-Fi. I'm not sure what happened to that, my assumption is the 5G patents are just way too expensive to justify the hardware set it up ad hoc like that compared to WiFi. Whoever is developing DECT these days may be way more willing to lower prices since they don't have a bunch of telcos to gouge.
DECT does support roaming between base stations. Most DECT base stations are designed as standalone devices, but Yealink, Snom, and other vendors do offer multi-cell solutions scalable to hundreds of base stations and thousands of devices.
Why is this part of the 5G spec?
DECT (which I last saw in devices that I was programming in 2005), zigbee and 802.11 are all local network mediums.
802.11ac maxes out at maybe 60-80m, zigbee maxes out at around 80m and DECT (last I used it) maxed out at maybe 100m.
Lora still works up to 15000m LoS.
In respect of 802.11ah, it's still under 1000m, outdoors, IIRC. Great for the use-case of covering your factory in sensors, not so for the use-cases that LoRa is intended for.
Range of DECT-2020 NR+ is comparable to Bluetooth Low Energy Long Range, which is plenty for a lot of applications but not in the same class as LoRa. But it's much higher bandwidth than LoRa and purportedly has determistic low latency, at least sufficient for audio, and they're marketing it for mission-critical and safety-critical applications.
We've already replaced the entire DECT infrastructure for WiFi phones with MS Teams in our company. Not nearly as reliable or functional but we make do with it.
It's not for phones.
https://www.rcrwireless.com/19980105/archived-articles/telec... [1998]
In the DECT Wikipedia page:
There has been only one major installation of DECT for public access: in early 1998 Telecom Italia launched a wide-area DECT network known as "Fido" after much regulatory delay, covering major cities in Italy. The service was promoted for only a few months and, having peaked at 142,000 subscribers, was shut down in 2001.
142K subscribers isn't quite your kitchen and den phone any more. :)
'99-'00 I worked on a Linux-based tablet where the first iteration used a DECT extension for data (DECT MMAP)... Wifi was not yet dominant enough to be the obvious winner.
BT wouldn’t be so bad if it was all abstracted away by a dongle that handled all the communication and presented itself to the OS as a dumb audio device.
Not much use if what you want to do is send a file.