_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI What is DECT-2020 New Radio (NR), and how big a deal is it? (2021)
micheljansen wrote 7 hours 34 min ago:
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.
mdekkers wrote 6 hours 48 min ago:
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.
joecool1029 wrote 1 day ago:
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: [1] (think DECT you could roam between
base stations with)
URI [1]: https://en.wikipedia.org/wiki/Personal_Handy-phone_System
wolrah wrote 22 hours 32 min ago:
> (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.
zackmorris wrote 1 day ago:
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.
ianburrell wrote 1 day ago:
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.
teleforce wrote 22 hours 10 min ago:
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]:
URI [1]: https://news.ycombinator.com/item?id=39727651
belthesar wrote 20 hours 14 min ago:
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.
teleforce wrote 14 hours 40 min ago:
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. [1] Ultra-wideband:
[1] [2] 100Gbps RF Sample Offload for RFSoC Using GNU Radio and
PYNQ: [2] [3] Analog Devices Apollo MxFE 0.5 to 55 GHz
Ecosystem:
URI [1]: https://en.wikipedia.org/wiki/Ultra-wideband
URI [2]: https://news.ycombinator.com/item?id=38555555
URI [3]: https://news.ycombinator.com/item?id=38458482
zackmorris wrote 1 day ago:
Hmm ya good points.
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.
idiotsecant wrote 16 hours 49 min ago:
So do it, mister ideas guy.
throw0101b wrote 1 day ago:
> 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:
* [1] > 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.
* [2] *
URI [1]: https://en.wikipedia.org/wiki/IEEE_802.11bn
URI [2]: https://grouper.ieee.org/groups/802/11/Reports/tgbn_update.htm
URI [3]: https://www.ieee802.org/11/Reports/802.11_Timelines.htm#TGbn
mytailorisrich wrote 1 day ago:
> 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.
kjellsbells wrote 14 hours 41 min ago:
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.
supertrope wrote 16 hours 53 min ago:
Anything needing high reliability is plugged in. Actual remote
surgery involves an on site backup surgeon, and redundant private
wired links.
_kb wrote 1 day ago:
Technical details and further background: [1] Full standard looks to
spread across ETSI TS 103 636 part 1 to 5 available here:
URI [1]: https://www.etsi.org/technologies/dect
URI [2]: https://www.etsi.org/committee/1394-dect
wkat4242 wrote 1 day ago:
Interesting, but DECT is already dead.
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.
mysteria wrote 1 day ago:
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.
wkat4242 wrote 1 day ago:
They are wireless. They're just rugged Android phones in fact.
nabla9 wrote 1 day ago:
It sounds like you did not read the article.
It's not for phones.
ale42 wrote 1 day ago:
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).
wkat4242 wrote 1 day ago:
It's pretty mediocre. But usable. DECT was much better but our
company wanted to remove the avaya PBXes from all sites.
kalleboo wrote 1 day ago:
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
buescher wrote 1 day ago:
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.
wkat4242 wrote 1 day ago:
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.
kalleboo wrote 1 day ago:
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.
buescher wrote 1 day ago:
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.
ale42 wrote 1 day ago:
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?)
wkat4242 wrote 1 day ago:
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.
ano-ther wrote 1 day ago:
It seems they have just released a developer kit
URI [1]: https://www.nordicsemi.com/Nordic-news/2024/01/The-nRF9161-SiP...
rpaddock wrote 1 day ago:
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.
martyvis wrote 1 day ago:
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?
usrusr wrote 1 day ago:
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.
gorkish wrote 1 day ago:
> 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.
noodlesUK wrote 1 day ago:
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)?
Why is this part of the 5G spec?
buescher wrote 1 day ago:
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.
lelanthran wrote 1 day ago:
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.
Lora still works up to 15000m LoS.
neilalexander wrote 1 day ago:
802.11ah, not 802.11ac.
lelanthran wrote 1 day ago:
good catch :-)
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.
Havoc wrote 1 day ago:
I suspect this is aimed at faster speed than lora if theyâre
talking about directly connected to backhaul
Aachen wrote 1 day ago:
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?
femto wrote 1 day ago:
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?
p_l wrote 1 day ago:
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.
_joel wrote 1 day ago:
Anyone else think of a cordless phone when the saw DECT?
kazinator wrote 1 day ago:
DECT is a surprisingly complex and capable system, which has been
used for metropolitan cellular service. [1] [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. :)
URI [1]: https://www.rcrwireless.com/19980105/archived-articles/telec...
vidarh wrote 1 day ago:
> 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.
Taniwha wrote 1 day ago:
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)
Maakuth wrote 1 day ago:
This is an evolution of the same radio techonology that was used in
those cordless phones.
jprd wrote 1 day ago:
DECT is awesome for wireless business headsets. Further range,
clarity and less interference compared to BT.
Nextgrid wrote 1 day ago:
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.
kwhitefoot wrote 1 day ago:
> presented itself to the OS as a dumb audio device.
Not much use if what you want to do is send a file.
nopurpose wrote 1 day ago:
zmodem :)
kwhitefoot wrote 1 day ago:
Those were the days!
rpruiz wrote 1 day ago:
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.
DIR <- back to front page