Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01

Jesus Sanchez Gomez <jesus.sanchez4@um.es> Fri, 03 April 2020 14:22 UTC

Return-Path: <jesus.sanchez4@um.es>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC883A1540 for <lake@ietfa.amsl.com>; Fri, 3 Apr 2020 07:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHtbBJojii5c for <lake@ietfa.amsl.com>; Fri, 3 Apr 2020 07:22:30 -0700 (PDT)
Received: from mx02.puc.rediris.es (outbound5sev.lav.puc.rediris.es [130.206.19.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A660B3A153D for <lake@ietf.org>; Fri, 3 Apr 2020 07:22:29 -0700 (PDT)
Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 033EMRcL023943-033EMRcM023943 for <lake@ietf.org>; Fri, 3 Apr 2020 16:22:27 +0200
Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 930D820AAC for <lake@ietf.org>; Fri, 3 Apr 2020 16:22:27 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon41.um.es
Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wm6VbFegKDQ3 for <lake@ietf.org>; Fri, 3 Apr 2020 16:22:27 +0200 (CEST)
Received: from iMac.local (unknown [88.148.107.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jesus.sanchez4) by xenon41.um.es (Postfix) with ESMTPSA id 66C4E1FF93 for <lake@ietf.org>; Fri, 3 Apr 2020 16:22:26 +0200 (CEST)
To: lake@ietf.org
References: <29734_1585730849_5E845521_29734_128_1_DAAA1C73.72FE4%dominique.barthel@orange.com> <B77992D8-230B-4CD4-A905-8A7D7AEE0884@ericsson.com> <27784_1585747918_5E8497CE_27784_494_1_DAAA597D.73034%dominique.barthel@orange.com> <28BF92FE-B0DC-4471-A4A4-C75BD2E5F03E@ericsson.com> <32275_1585754326_5E84B0D6_32275_32_1_DAAA7842.730FF%dominique.barthel@orange.com> <25933FC0-E0B8-43D0-A9F9-55AD11D7761F@ericsson.com> <22197_1585843918_5E860ECE_22197_124_1_DAAB6BB6.73184%dominique.barthel@orange.com>
From: Jesus Sanchez Gomez <jesus.sanchez4@um.es>
Message-ID: <8541a330-b695-cf49-d460-74343828fb0a@um.es>
Date: Fri, 3 Apr 2020 16:22:25 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <22197_1585843918_5E860ECE_22197_124_1_DAAB6BB6.73184%dominique.barthel@orange.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-FEAS-CONTENT-MODIFICATION:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:mime-version:content-type; bh=x0fiqV/OIBNPHSz4A5XmPeAgwpMvrfEYsDWUCEi6yy8=; b=wuHfoasc1FXdlyO1st0A4LpSVEw1meGCfmjm+UNYQszTfv5TIuRY6PXmhUF8uqqHxc1xtDbwTPEe rqEkJ/liz/3Mjph29bAhP2PLT9zJGPSlH8BPanZz8g01n8J2F/6m2US7Pu4UrvGSUZFJ0RUCHRQ9 NzNt5DMLfWBO9vbmjJInxj0GVkJhgO1Bqo5Em4MSuuZKP7kGpY9F34UG2XTvya/qN/PQ/uTtSBis exR3aqJNKcFhtUMh2YMLPBhOxBCzPIM3s5L+10LHjqrBPlDVoGpNlkM6Hn6sqV+QjqVzRY2Q4ZCP 0AC3chky6dgY3h6CUqyEhy5jFIKI1Vdfw5QnTQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/Wm-KRxMmJv1PSXarBQVVOvc7TKw>
Subject: Re: [Lake] LoRaWAN use case; Re: WGLC for draft-ietf-lake-reqs-01
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 14:22:31 -0000

Hello Dominique, all,

I think that it would be a nice addition to the document to consider the 
reality of commercially available LoRaWAN certified products' behaviour 
for EU (e.g. Microchip's RN2483, all the microphython compatible ones, 
LMiC).

I'm currently researching popular LoRaWAN certified products' datasheets 
trying to gather more information on this matter.

As the ETSI states, the 36 continuous burst is possible (considering 
RX1_delay, and RX1/RX2 windows of Class A) in theory.
However, expecting that all LoRaWAN modules are going to implement such 
functionality is uncertain AFAIK. Yo previously mentioned this in one of 
your recent messages.

Please, would you kindly provide a few names of LoRaWAN commercially 
available modules, I will take a look at how those manage said 36 
seconds continuous burst.

Another thing to consider is the configuration of optional sub-bands 
with their respective duty-cycle, that would further increase the amount 
of data that you can send in a short period of time.

Best Regards,

-- 
Jesús Sánchez Gómez
Contratado predoctoral // Phd Student. Fundación Séneca. Comunidad Autónoma de la Región de Murcia
+34 868 88 96 74
+34 635 33 26 09
jesus.sanchez4@um.es
Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain