[HN Gopher] What is DECT-2020 New Radio (NR), and how big a deal...
___________________________________________________________________
What is DECT-2020 New Radio (NR), and how big a deal is it? (2021)
Author : teleforce
Score : 83 points
Date : 2024-03-28 10:03 UTC (12 hours ago)
(HTM) web link (blog.nordicsemi.com)
(TXT) w3m dump (blog.nordicsemi.com)
| rpruiz wrote:
| 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.
| _joel wrote:
| Anyone else think of a cordless phone when the saw DECT?
| Maakuth wrote:
| This is an evolution of the same radio techonology that was
| used in those cordless phones.
| jprd wrote:
| DECT is awesome for wireless business headsets. Further
| range, clarity and less interference compared to BT.
| Nextgrid wrote:
| 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:
| > 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:
| zmodem :)
| kwhitefoot wrote:
| Those were the days!
| Taniwha wrote:
| 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)
| kazinator wrote:
| DECT is a surprisingly complex and capable system, which has
| been used for metropolitan cellular service.
|
| 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. :)
| vidarh wrote:
| > 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.
| Aachen wrote:
| 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?
| p_l wrote:
| 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.
| femto wrote:
| 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?
| noodlesUK wrote:
| 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?
| Havoc wrote:
| I suspect this is aimed at faster speed than lora if they're
| talking about directly connected to backhaul
| lelanthran wrote:
| 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:
| 802.11ah, not 802.11ac.
| lelanthran wrote:
| 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.
| buescher wrote:
| 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.
| martyvis wrote:
| 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:
| 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:
| > 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.
| ano-ther wrote:
| It seems they have just released a developer kit
| https://www.nordicsemi.com/Nordic-news/2024/01/The-nRF9161-S...
| rpaddock wrote:
| 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.
| buescher wrote:
| 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:
| 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.
| ale42 wrote:
| 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:
| 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.
| buescher wrote:
| 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.
| kalleboo wrote:
| 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.
| wkat4242 wrote:
| 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.
| kalleboo wrote:
| 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
| ale42 wrote:
| 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:
| It's pretty mediocre. But usable. DECT was much better but
| our company wanted to remove the avaya PBXes from all sites.
| nabla9 wrote:
| It sounds like you did not read the article.
|
| It's not for phones.
| mysteria wrote:
| 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:
| They are wireless. They're just rugged Android phones in
| fact.
| _kb wrote:
| Technical details and further background:
| https://www.etsi.org/technologies/dect
|
| Full standard looks to spread across ETSI TS 103 636 part 1 to 5
| available here: https://www.etsi.org/committee/1394-dect
| throw0101b wrote:
| > _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:
|
| * 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
| mytailorisrich wrote:
| > _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.
| zackmorris wrote:
| 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:
| 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.
| zackmorris wrote:
| 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.
| teleforce wrote:
| 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]:
|
| https://news.ycombinator.com/item?id=39727651
| belthesar wrote:
| 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.
| joecool1029 wrote:
| 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)
| wolrah wrote:
| > (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.
___________________________________________________________________
(page generated 2024-03-28 23:01 UTC)