IETF Logo Mail Archive

Re: [lp-wan] Problem in LoRaWAN profile definition

ivaylo petrov <ivaylo@ackl.io> Tue, 16 July 2019 09:38 UTC

Return-Path: <ivaylo@ackl.io>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86631201ED for <lp-wan@ietfa.amsl.com>; Tue, 16 Jul 2019 02:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ackl-io.20150623.gappssmtp.com
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 QnO_-RrvEJUA for <lp-wan@ietfa.amsl.com>; Tue, 16 Jul 2019 02:38:51 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77D71201E7 for <lp-wan@ietf.org>; Tue, 16 Jul 2019 02:38:50 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id f17so17949936wme.2 for <lp-wan@ietf.org>; Tue, 16 Jul 2019 02:38:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=STKMpTOK7GcBiFrplFMY8h0pExoATEBG5bPsHGyGZ7k=; b=QQAKnoY7LRRUZAGMNC5sYpINH6BwzJF62XxPVMhSoRiLlQaKC0GgHT5Rj5ZzjK6LQj IWkXcm5Fj0Pi7n+fiGo+Dd7s8ZXlGQySQsNA+QrAwaH9C5krp42tRsir9oJ7hvVachuD lHNFyPokCGl1sW/CIVPr041tIUARtA/3LAq1ohW7dYl59UwptSSX8SdkMZzkz4jbDcYJ vDXbcjp+SQsV1uCqSBUbYDtoA12TVYijuGssBNCNhqjSUHSqk23BBQTFt4myJ0v8dxKm Gx7PIL1ZyRRbqeod3Q59ytM9k53WN93EMMUZt/z4R/ox4j4pEEuN+DEnWD3je6FkBauY le+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=STKMpTOK7GcBiFrplFMY8h0pExoATEBG5bPsHGyGZ7k=; b=o29ClqUwdEOsuly53C6PetyttxB3wuN4BnMgHRb3GowMm8joPf0kU3QzVivXjxmcF6 MMcvwKiTChzu9/EyTA2c/clhTaedIRw5nuA2zyOTWLwcn1bl+qg+FZLHXtMADKBU97mW JhrhaqW8EAYMj2Dj/Evq8jv9FManecEPPpQ8AVNIt0GrIsWBpS8U6aX2lv0j9tGbJJbd /43VYHZ7cEdPLSwNocPIwT8cJGB3etVYuaRO2kAKf6lxpxtL4T127Q7xA+DdsN3LNGyo WxfguHfop9wK1SlFdPzNdEgj9wzvDQ0XUdgsD81rPR0beyWpMw4e5QAg6s1U11RRso4M kh1g==
X-Gm-Message-State: APjAAAX3OWWro8k0+M2SfIpJmQi++VB/yePjTkUFA7/dmgn+ejr59Nu+ rOFS/5BOrJHifUomTOvESE395IWvZDXO5b2YUeE=
X-Google-Smtp-Source: APXvYqz7F+FM7MVKxfwfpv4/DNdvC3aennccZ8zf7n9KYG8ckWzY/tSidlibIx3MQei38HSAHdMelOrFCjTRXTcn1ck=
X-Received: by 2002:a1c:b68a:: with SMTP id g132mr30810689wmf.66.1563269929239; Tue, 16 Jul 2019 02:38:49 -0700 (PDT)
MIME-Version: 1.0
References: <CALJ+G3XA8319Y3ty+3J+fn8qwdALHY3s+fk6X2nKMiN1_2rh7Q@mail.gmail.com>
In-Reply-To: <CALJ+G3XA8319Y3ty+3J+fn8qwdALHY3s+fk6X2nKMiN1_2rh7Q@mail.gmail.com>
From: ivaylo petrov <ivaylo@ackl.io>
Date: Tue, 16 Jul 2019 11:38:22 +0200
Message-ID: <CAJFkdRzZE3FkfLKOJXnzRJSXsH7STdc_qkv7hcuR3eVciwr_Mw@mail.gmail.com>
To: Rodrigo Muñoz Lara <rmunozlara@ing.uchile.cl>
Cc: lp-wan <lp-wan@ietf.org>, Juan Millan Castillo <jjmillancas@gmail.com>, Sandra Cespedes <scespedes@ing.uchile.cl>
Content-Type: multipart/alternative; boundary="000000000000d21d14058dc92479"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/zBlX61JlHR818VN7YLoa4N-a0Iw>
Subject: Re: [lp-wan] Problem in LoRaWAN profile definition
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 09:38:54 -0000

Dear Rodrigo,

Thank you for your email! Find my answers below (in blue).

Best regards,
Ivaylo Petrov


On Tue, Jul 16, 2019 at 7:00 AM Rodrigo Muñoz Lara <rmunozlara@ing.uchile.cl>
wrote:

> Dear Author,
>
> On page 10, in the draft "draft-ietf-lpwan-schc-over-lorawan-02", indicates that in the case the end-device is the fragmentation transmitter, and the SCHC gateway the fragmentation receiver.  Two fragmentation rules are defined regarding the *FPort*:
>
>
>    o  *FPortUpShort*: SCHC header is only one byte.  Used when
>       fragmentation is required and payload size is less than 381 bytes.
>
>    o  *FPortUpDefault*: SCHC header is two bytes.  Used for all other
>       cases: no fragmentation required or payload size is between 382
>       and 1524 byte.
>
>
> What happens if the payload size is 381 bytes?. My question is because if you see the first rule, said: "payload size is less than 381 bytes" and the second rule said: "payload size is between 382 and 1524 byte".
>
> [IP]: The text should indeed read *less than or equal to 381 bytes.* Thank
you for pointing this out!

>
> What is the criterion for choosing these sizes?
>
> [IP]: For FPortUpDefault we needed to support at least the IPv6 required
1280 bytes (see rfc2460 sec 5). Due to the tile size, we support slightly
more than that.
For FPortUpShort, the criteria was to minimize overhead in case of small
packets that are still too big to fit in only one L2 packet. Based on that
we decided to use 1 byte of SCHC header (as we always need some space for
FCN, we can not go below that without reducing too much the MTU and having
byte aligned operations is simpler to implement, thus reducing the chance
of issues in the implementation stage). From that, as indicated in 5.5.1.
and 5.5.1.1., you can have only 127 tiles. As the tile size was chosen to
be 3 bytes, this leads to a packet of at most 381 bytes.

> We can choice the first rule assuming that should say "payload size is less than or equal than 381 bytes"?
> 	
>
> Thanks and Regards
>
> -------------------------------------
> Rodrigo Munoz Lara
> Department of Electrical Engineering
> Universidad de Chile
> Santiago, Chile
> rmunozlara@ing.uchile.cl
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>

v2.23.0 | Report a Bug | By Email