<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">

<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">

<!--<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">-->

<!--<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
 -->
<!ENTITY standndp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>



]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-minaburo-6lpwa-yang-lora-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters abbrev="Abbreviated Title" -->

    <title>YANG module for LoRa Networks</title>

    <author fullname="Ana Minaburo" initials="A.M." role="editor"
            surname="Minaburo">
      <organization>Acklio</organization>

      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>2bis rue de la Chataigneraie</street>
          <code>35510</code>
          <city>Cesson-Sevigne</city>
          <region>Bretagne</region>
          <country>FR</country>
        </postal>
        <email>ana@ackl.io</email>
      </address>
    </author>
    
    <author fullname="Laurent Toutain" initials="L.T." 
            surname="Toutain">
      <organization>Telecom Bretagne</organization>

      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>2 Rue de la Chataigneraie</street>
          <code>35510</code>
          <city>Cesson-Sevigne</city>
          <region>Bretagne</region>
          <country>FR</country>
        </postal>
        <phone>+33299127026</phone>
        <email>laurent.toutain@telecom-bretagne.eu</email>
      </address>
    </author>
    

    <author fullname="Yannick Delibie" initials="Y.D." 
            surname="Delibie">
      <organization>Kerlink</organization>

      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>1 rue Jacqueline Auriol</street>
          <code>35235</code>
          <city>Thorigne-Fouillard</city>
          <region>Bretagne</region>
          <country>FR</country>
        </postal>
        <phone>+33299122900</phone>
        <email>yannick.delibie@kerlink.fr</email>
      </address>
    </author>
    
   
    <date/>
    
    <!-- date month="March" year="2007" / -->

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
 in the current day and month for you. If the year is not the current one, it is 
 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Applications and Real-Time Area (art)</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>LoRa</keyword>
    <keyword>Long-range Radio</keyword>
    <keyword>YANG module</keyword>
    <keyword>LR-WAN</keyword>
    <keyword>LPWAN</keyword>
    <keyword>LPWA</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document presents a YANG module definition for managing LoRa-based devices.</t>
    </abstract>
  </front>

  <middle>
  
    <section title="Introduction">
       <t>This document provides a YANG module description for managing a LoRa endpoints.</t>
    
       <t>SemTech <xref target="LoRa" /> (c) is a low-rate, low-power, long-range radio technology. It could be used as a base radio technology for building Low-Rate Wide-Area Networks (LR-WAN), also known as LPWA (Low-Power Wide Area). SemTech <xref target="LoRa"/> (c) has the following characteristics:        
            <list style="symbols">
            <t>Works in narrow, license-free (ISM) bands with good propagation properties (&lt; 1GHz)</t>
            <t>Low- to very-low throughput (270 bps--200 kbps)</t>
            <t>Low-power operation (25 mW in Europe)</t>
            <t>Far-Reaching communication capabilities (20 km with line-of-sight, several km in urban environment)</t>
            <t>Strong channel access restrictions (1% to 10% duty cycling)</t>
            </list>
        </t>

        <t>The management of LoRa-based devices can be done through a standard approach, compatible with the best network-operator practices, namely NETCONF or RESTCONF. A formal definition of the parameters and the values to be managed is thus required, which can be done with the YANG module language. The following document presents a YANG module definition for managing a LoRa-based end-device.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="LoRa Data Model">
      <t>The data model has the following structure for Lora configuration:</t>

        <figure align="left" anchor="TreeModel">
            <!-- preamble>Preamble text - can be omitted or empty.</preamble -->
            <artwork align="left"><![CDATA[

+- RW ietf-lora
    +- RW Lora 
       +- RW Mode
       |   +- RW Channel Bandwidth      enumeration
       |   +- RW Coding Rate            enumeration
       |   +- RW Spreading Factor       int8
       +- Physical Layer
       |   +- RW Preamblelength         int32
       |   +- RW Channel Frequency Range  enumeration
       |   +- RW Channel                int8
       |   +- RW SymbolTimeout          int32
       +- MAC Layer
           +- RW FrPayloadEncryption    boolean
           +- RW Delay                  int32    
           +- RW FixlengthPayloadOn     boolean
          
            ]]></artwork>
            <postamble>The data model defines a state container Mode which include the three principal characteristics of the LoRA interface which determine the parameters of the channel </postamble>
        </figure>

    </section> <!-- Lora Data Model -->

    <section title="LoRa YANG module">
       <t>This model imports typedefs from [RFC6991].</t>
        <figure align="left" anchor="YangModel">
            <!-- preamble>Preamble text - can be omitted or empty.</preamble -->
            <artwork align="left"><![CDATA[


module lora {

    namespace "urn:lora";
    prefix lora;

    import ietf-interfaces {
       prefix if;
    }

    organization
      "Acklio";

    contact
    "Ana Minaburo
     ana@minaburo.com";

    description
      "This module contains a collection of YANG definitions for 
   configuring the LORA () network interface.
   
   Copyright (c) 2015 IETF Trust and the persons identified as 
   authors of the code. All right reserved.
   
   Redistribution and use in source binary forms, with or 
   without modification, is permitted pursuant to, and subject 
   to the license terms contained in, the Simplified BSD License 
   Relating to IETF Documents
   (http://trustee.ietf.org/license-info)

   This YANG module version is part of draft-minaburo-yang-lora-00;
   see the draft itself for full legal notices.";

    revision 2015-11-01 {
      description
        "Initial Description";
      reference
        "LoRa MAC Class A Specification R3.1 by Semtech";
    }


    grouping mode {
       description "Principal factors to change modulation";
       leaf channel-bandwidth {
          description "Physical Channel Bandwidth"; 
          type enumeration {
            enum 125 { description "125 KHz"; value 0; }
            enum 150 { description "150 KHz"; value 1; }
            enum 500 { description "500 KHz"; value 2; }
          }
       }

       leaf coding-rate {
         description "LORA error correction scheme";
          type enumeration {
             enum 4_5 { description "value 1; }
             enum 4_6 { value 2; }
             enum 4_7 { value 3; }
             enum 4_b { value 4; }
          }
       }

       leaf spreading-factor {
          description "Modulation to enable spread signals to 
                       transmit signals at the same time";
         type uint8 {
           range "6 .. 12";
       }
    }

    }

    augment "/if:interfaces/if:interface" {
         description "          // To be defined later";
        when "if:type = 'ianaieft:lora'";
          description "LORA channel";

         container lora {
           uses mode;
             container physical-layer {
                description "LORA phisical layer";
                leaf preamble-length {
                   description "Header packet definition";
                  type int32;
                  default 7;
           }

               leaf channel-frequency-range {
                 description "Band Choice depends on Country";
                 type enumeration {
                 mandatory true;
                 enum europe;
                 enum usa;
                 enum japan;
                 enum china;
                }
              }

              leaf channel {
                 description "Physical Channels";
                 type uint8 {
                   range "0..10";
                 }
               }

              leaf symbol-timeout {
                  description "Waiting the free band";
                 type uint32;
                 }
               }

              container mac-layer {
                  description " LORA MAC layer format";
                  leaf payload-encryption {
                      description "Known if the encryption is used";
                     type boolean;
                     default "false";
                   }

                  leaf delay {
                     description "Delay value";
                     type int32;
                  }

                  leaf fixed-length-payload {
                     description "If Modulation is not variable";
                    type boolean;
                    default "false";
                   }
             }
          }
      }
}

 
 ]]></artwork>
            <postamble>The data model defines a state container Mode which include the three principal characteristics of the LoRA interface which determine the parameters of the channel </postamble>
        </figure>
        
    </section> <!--LoRa YANG module -->


    <section anchor="Acknowledgements" title="Acknowledgements">
    <t> We want to thank Alexander Pelov for all his inputs and corrections to this work </t>
    </section>
    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>All drafts are required to have a security considerations section.
      See <xref target="RFC3552">RFC 3552</xref> for a guide.
      TO DO </t>
    </section>
  </middle>
  
  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
        &RFC2119;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

         &RFC3552;

<!--      <reference anchor="IEEE.802-15.4k">
		<front>
			<title>
				 Low-Rate Wireless Personal Area Networks (LR-WPANs) - Amendment 5: Physical Layer Specifications for Low Energy, Critical Infrastructure Monitoring Networks., IEEE 802.15.4k
			</title>
			<author>
			<organization>Institute of Electrical and Electronics Engineers</organization>
			</author>
			<date month="" year="2013"/>
		</front>
		<seriesInfo name="IEEE" value="Standard 802.15.4"/>
	</reference>
	
      <reference anchor="LTN001">
		<front>
			<title>
				 Low Throughput Networks (LTN); Use Cases for Low Throughput Networks, ETSI GS LTN 001
			</title>
			<author>
			<organization>European Telecommunications Standards Institute</organization>
			</author>
			<date month="" year="2014"/>
		</front>
		<seriesInfo name="IEEE" value="ETSI GS LTN 001"/>
	</reference>
    <reference anchor="LTN003">
		<front>
			<title>
				 Low Throughput Networks (LTN); Protocols and Interfaces, ETSI GS LTN 003
			</title>
			<author>
			<organization>European Telecommunications Standards Institute </organization>
			</author>
			<date month="" year="2014"/>
		</front>
		<seriesInfo name="IEEE" value="ETSI GS LTN 003"/>
	</reference>

    <reference anchor="SigFox">
		<front>
			<title>
		https://web.archive.org/web/20150628225901/http://www.sigfox.com/en/#!/technology
			</title>
			<author>
			<organization>SigFox</organization>
			</author>
			<date month="June" year="2015"/>
		</front>
	</reference>-->

    <reference anchor="LoRa">
		<front>
			<title>			https://web.archive.org/web/20150510011904/https://www.semtech.com/wireless-rf/lora.html
			</title>
			<author>
			<organization>Semtech</organization>
			</author>
			<date month="May" year="2015"/>
		</front> 
	</reference>
	
	
	
    </references>

<!--
    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
-->

    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>
