Re: [E-impact] WindEurope Annual Event

[Rudolf van der Berg <[e-mail]>]

Agree with Jari, with the caveat that the 3GPP isn't good at "running
code". Many of the features that are described on paper aren't implemented
in code and those that are implemented in code aren't always working the
same or active in either a device or a network.

I recently did a project for a client who does large scale industrial
energy metering. It was an evaluation of their and other firms experience
with mobile networking technologies and an advice on what technology they
would bet the firm on for the next 5 years. NB-IOT isn't supported in some
of their major markets, so that was a no go. Despite LTE-M looking great on
paper for their use case, their experience in reality was that:
-  LTE-M isn't supported widely on mobile networks in Europe,
-  LTE-M support from device manufacturers is minimal,
-  LTE-M roaming doesn't work as advertised (or not at all) between some
MNOs,
-  LTE-M devices may receive just enough signal to keep them locked onto
one network, but just too little to send data (probably a firmware bug in
the modem), instead of switching to another mobile network.
- LTE-M issues are blamed by the MNO on the device/modem manufacturer, they
blame it on the MNO and network manufacturer (Nokia, Ericsson, Huawei), who
either don't respond or blame it on their competitors, the MNO, the
manufacturer or the client.
- etc etc
The conclusion was that LTE CAT-1 is the future and not LTE-M (or NB-IOT).
It doesn't support the cool features, but it is similar what consumers use
and works on all networks, with roaming.

In 5G there is an M2M version called REDCAP (REDuced CAPability) which
promises even more magic for IoT type applications. However here too, those
functions aren't present in the initial releases and network and device
support is unknown. I was told by one person that REDCAP had learned from
the LTE-M vs LTE CAT-1 fight. He said that it is supposed to run any
standard 5G network, but when challenged that person couldn't show me any
industry source (he too had heard it from someone else). So I hope REDCAP
is better, but I'm waiting 5 years or so until we have some actual
statistics and working devices.



Op wo 27 mrt 2024 om 00:27 schreef Jari Arkko <[e-mail]>:

> Of course the variability of green power sources is an issue. To an extent
> we can deal with by varying consumption, e.g., turn the aluminum melters
> off when power is non-green or scarce, etc. Or data centers :-)
>
> Part of the problem is of course information sharing, to make sure
> consumption knows about the state of production. Here Internet helps,
> obviously :-) But of course there are also local means, e.g., a site that
> has its own green power knows how much it can consume, but even so, it may
> still need to communicate to parties it is serving, e.g., it may not accept
> new jobs unless there’s enough energy and so on.
>
> Then a follow-up on this:
>
> > In 5G we can have low and high power slices which are configured to
> consume high or low power respectively. For example, Low-power slices may
> use narrower channels, lower frequencies, and simpler antenna
> configurations to reduce energy consumption. Traffic is shifted to low or
> high power slices based on availability of renewable energy.
> >
> > Does this work?
>
> You can of course have network equipment configurations or virtual
> configurations that are geared towards a particular tradeoff. This is true
> of slicing as well.
>
> However, for 5G perhaps a bigger question is what radios are on and how
> often and when they can sleep. The radio part is the largest fraction of
> energy use. But there’s a lot of radios, antennas, sites, coverage, even
> overlapping coverage and the usage can vary wildly. Think of city business
> district during work hours and a lot off demand, but more empty in the
> night when demand shifts to other areas. Potential energy savings don’t
> come from a particular user group but rather the aggregate. When we can
> design our system architectures so that the number of
> must-always-be-broadcasting-every-millisecond parts is minimized, that the
> overall number of radios on at all  can be scaled according to user demand,
> that equipment can fall asleep and wake up in extremely short time periods
> so that it can save energy when there are no packets to send, etc. And
> remember that packet transmission in mobile networks is highly
> scheduled/controlled which helps the equipment make well-informed decisions
> at least in short timescales.
>
> Jari
>
> --
> E-impact mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e-impact
>