Re: [lp-wan] overview draft with some text...

[Juan Carlos Zuniga <[e-mail]>]

Hi Jiazi,

From: lp-wan [mailto:[e-mail]] On Behalf Of Jiazi Yi
Sent: October 30, 2016 6:59 PM
To: Stephen Farrell <[e-mail]>
Cc: [e-mail]
Subject: Re: [lp-wan] overview draft with some text...

Hi,


On 30 Oct 2016, at 00:46, Stephen Farrell <[e-mail]<mailto:[e-mail]>> wrote:


Hiya,

On 29/10/16 23:19, Jiazi Yi wrote:

Dear Stephen,

Thanks a lot for the work!

A general comment before going into details:

When introducing characteristics and performance of different
technologies, I think we need to pay attention that:

1) focus on the objective characteristics, such as frequency band,
bandwidth, data rate, etc. I would avoid using text like “foo has
battery life of XXX years” or “bar can support YYY devices in a
single cell”. Those kind of characteristics depend on highly on the
configuration of the network, application traffic pattern, network
environment, etc. It’s very hard to extract useful information from
such kind of assertions.

Fully agree with editing out any such statements. Feel free to
point out any that are in there now, but I'll also do a pass for
that myself later on.

Some examples:

4.2.2:
Specific targets for NB-IoT include: <snip>  battery life of
  over 10 years, ~55000 devices per cell …

4.3.2:
   SIGFOX LPWAN autonomous battery-operated devices send only a few
   bytes per day, week or month, allowing them to remain on a single
   battery for up to 10-15 years.





2) For each technology, we talk only the current characteristics, not
the targeting characteristics (especially those long target).

I'm not sure I agree there. If there are changes planned that'd
happen in the next say 5 years, then it seems like those would
be fine input for the WG to consider.

I agree.


Of course, I do agree that
the WG will need to be exercise judgement about how they consider
any such plans, as we're all prone to being a bit optimistic
about the future:-)

FWIW, I think anything written down as an IETF contribution or
that can be referenced from one should be good input to the WG.

What the WG choose to conclude from such input is of course
another question. But that's just me. Whether or not the WG have
consensus to regard some input or claim as outlandish or worth
documenting and analysis is not my call.



3) It’s welcome to report implementation status of different
technologies, but if the contributors choose to do so, please provide
a bit more details (such as the scale of the deployment, applications
running over it, etc.), with appropriate references.

I'm curious myself about some of the current implementations and
deployments and whether those might constrain the work here. But
I'm not clear about the level of detail the WG need about that.

Personally, I’m very interested in knowing the current deployment status. If such information could be disclosed, even if briefly, would be welcome. But I would like to see the technical aspects of the deployments to understand how they works.

For example, when reading:

As of today, the SIGFOX LPWAN/LTN has been fully
   deployed in 6 countries, with ongoing deployments on 14 other
   countries, which in total will reach 316M people.

I would like to know at least: how many devices are actually deployed? What’s the typical coverage of a cell? What’s the maximum number of sensors in a cell? What does the traffic look like?





The purpose is to have an objective standard as possible for all the
technologies listed in the draft. We have to admit that, although we
(all?) agree, and called out explicitly that this document is NOT
intended to compare which technology is better, we couldn’t stop the
readers from making such kind of comparison.

Not sure I'm following the point there.

One thing I do think though - regardless of whether or not the
WG decide this draft ought end up as an RFC, we still only need
the text here to be sufficiently clear for the WG to do it's
job. And if we aim for perfect wording then we'll probably take
a lot of time to just not achieve that. So while we do need to
ensure that the overall text doesn't give a wrong impression, I
figure being careful to not waste time aiming for a non-useful
level of perfection will be better.

Agree. The point I want to make is that we use clear and technical text, and avoid marketing words.

[JCZ] I understand your point about avoiding marketing words for our technical purposes. However, these networks support extremely different use cases, and traffic characteristics strongly depend on the vertical application. Hence, it is hard to give a figure without describing the commercial application. I could for instance mention:
- Defibrillator: about 1 message a day,
- Beehive: a few messages a week,
- Trash bin: about 1-5 messages a week,
- Alarm system: 5-10 messages a day.
Then you can have use cases which vary even more, like a parking sensor traffic pattern would vary by the hour depending on whether this is a business day, weekend or holiday, as well as whether it is in a commercial or residential zone; or an animal/ parcel tracker traffic pattern would depend on the specific utilization by the user.
As you can see, it is hard to concentrate on just a couple of use cases, or give a one-size-fits-all traffic figure. That’s why I used the generic language in section 4.3.2 of draft-zuniga that you quoted above. Perhaps adding some examples would help conveying the message?
OTOH, the capacity of a sigfox BS mainly depends on the number of messages generated by the devices, and not on the number of devices. The battery life also depends on the number of messages generated by the device, but it is important to keep in mind that these devices will last several years, some of them even buried underground. The coverage of the cell also depends on the link budget and on the type of deployment (urban, rural, etc.), and those figures are already mentioned.

Best,

Juan Carlos

cheers

Jiazi



Cheers,
S.




regards

Jiazi


On 29 Oct 2016, at 01:57, Stephen Farrell
<[e-mail]<mailto:[e-mail]>> wrote:


Hiya,

I've incorporated descriptive text about some of the "input"
technologies for lpwan in -01 of the overview draft. [1] That
includes text from a lora draft that Alper and I also posted
recently [2] and from the existing sigfox and nb-iot drafts. Next
up will be adding text from the gap analysis work in the places
indicated. I hope to post that before the cutoff. We may also get
text on WI-SUN by then too.

Comments on any inaccuracies or omissions in [1] are of course very
welcome. There's a github repo [3] if anyone prefers that. (Though
my github foo is modest so bear with me if taking that approach:-)
I'll make sure that any substantive discussion initiated on github
is reflected to the list.

Cheers, S.

[1] https://tools.ietf.org/html/draft-farrell-lpwan-overview-01 [2]
https://tools.ietf.org/html/draft-farrell-lpwan-lora-overview-01
[3] https://github.com/sftcd/lpwan-ov


_______________________________________________ lp-wan mailing
list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/lp-wan


_______________________________________________ lp-wan mailing list
[e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan