Subject: [lp-wan] Ticket #23: NB-IoT

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Feb 2018 14:17:17 +0100

<ER>: I don't really know how is expected to be the abstraction when a
device is multiRAT capable and the diagram seems to suggest that there is
only one context even if multiple applications are used. In the case of
NB-IOT each bearer can be map to a different transmission mode (for
example, acknowledged, unacknowledged or transparent) the last one do not
have segmentation support, would it then have only one context or would
require two context if application data is map to an additional
non-transparent transmission type ?

<ER> One possible use case that has been presented for radio technologies
is the V2V (D2D) and coverage extension by relaying of radio signals, in
3GPP this is called SIDELINK. I wonder if such value definition would be
useful here too for future compatibility reasons
<Authors> This seems to be out of the charter of the document, where Star
topology is retained.
comment:2 <https://trac.ietf.org/trac/lpwan/ticket/23#comment:2>

<ER> For Rule Id, what would be the case for multirat devices? would they
have a different set of rules per radio access technology?
comment:3 <https://trac.ietf.org/trac/lpwan/ticket/23#comment:3>

<ER> I understand well, fragmentation will be always done if a packet is
not fitting a single L2 unit. In NB-IOT this might not always be necessary,
but still, the compression part of SCHC is of interest. One possibility is
to set the MTU to something very large so fragmentation does not happen, or
maybe it can be disabled by an implementation, but shouldn't be expected by
a receiver of the packet.
Another issue is the determination of the MTU of the L2, especially with
the current architecture since in some technologies there is and rate
adaptation function for some transport channels that set a different MTU in
L2 depending on what is the radio channel quality. That would mean that the
fragmentation part of the protocol should be done close to the radio
gateway from the network perspective and requires hooks from MAC layer to
SCHC (also in the devices) in order to know what is the particular
transmission MTU
comment:4 <https://trac.ietf.org/trac/lpwan/ticket/23#comment:4>

<Authors> Most of this inputs may be solved in the corresponding technology
document.