lorawan协议栈及sx1301网关手册lorawan 1 0 2 specification

1、123LoRaWAN SpecificationCopyright 2016 LoRa Alliance, Inc. All rights reserved.4NOTICE OF USE AND DISCLOSURECopyright LoRa Alliance, Inc. (2015, 2016). All Rights Reserved.567891011121314151617181920212223242526272829303132333435363738394041424344The information within this document is the property

2、of the LoRa Alliance (The Alliance) and its use and disclosure are subject to LoRa Alliance Corporate Bylaws, Intellectual Property Rights (IPR) Policy and Membership Agreements.Elements of LoRa Alliance specifications may be subject to third party intellectual property rights, including without lim

3、itation, patent, copyright or trademark rights (such a third party may or may not be a member of LoRa Alliance). The Alliance is not responsible and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual propertyrights.This documen

4、t and the information contained herein are provided on an AS IS basis and THE ALLIANCE DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREINWILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUTLIMITATION ANY INTELL

5、ECTUAL PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,TITLE OR NONINFRINGEMENT.IN NO EVENT WILL THE ALLIANCE BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OFB

6、USINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.The above notice and t

7、his paragraph must be included on all copies of this document that are made.LoRa Alliance, Inc.2400 Camino Ramon, Suite 375 San Ramon, CA 94583Note: All Company, brand and product names may be trademarks that are the sole property of their respective owners.452016 LoRa AlliancePage 1 of 70The author

8、s reserve the right to change specifications without notice.LoRaWAN Specification12LoRaWAN Specification34567891011121314151617Authors:N. Sornin (Semtech), M. Luis (Semtech), T. Eirich (IBM), T. Kramp (IBM),O.Hersent (Actility)Version: V1.0.2 Date: 2016 July Status: Final2016 LoRa AlliancePage 2 of

9、70The authors reserve the right to change specifications without notice.LoRaWAN SpecificationContents1 Introduction612345678910111213141516171819202122232425262728293031323334353637383940414243444546474849501.11.2LoRaWAN Classes6Conventions72 Introduction on LoRaWAN options82.12.2LoRaWAN Classes8Spe

10、cification scope9Class A All end-devices103Physical Message FormatsUplink Messages11Downlink Messages11Receive Windows...63.3.7First receive window channel, data rate, and start12Second receive window channel, data rate, and start12Receive window duration12Rece

11、iver activity during the receive windows12Network sending a message to an end-device12Important notice on receive windows13Receiving or transmitting other protocols134MAC Message Formats14MAC Layer (PHYPayload)14MAC Header (MHDR field).1 Message type (MType bit field)154.2.2 Major version

12、 of data message (Major bit field)154.3MAC Payload of Data Messages (MACPayload)164.3.1 Frame header (FHDR)164.3.2 Port field (FPort)194.3.3 MAC Frame Payload Encryption (FRMPayload)204.4Message Integrity Code (MIC)20MAC Commands21Link Check commands (LinkCheckReq, LinkCheckAns)22Link ADR commands (

13、LinkADRReq, LinkADRAns)22End-Device Transmit Duty Cycle (DutyCycleReq, DutyCycleAns)25Receive Windows Parameters (RXParamSetupReq, RXParamSetupAns)25End-Device Status (DevStatusReq, DevStatusAns)26Creation / Modification of a Channel (NewChannelReq, NewChannelAns, DlChannelReq, DlChannelAns)26Settin

14、g delay between TX and RX (RXTimingSetupReq, RXTimingSetupAns)29End-device transmission parameters (TxParamSetupReq, TxParamSetupAns)29End-Device Activation31Data Stored in the End-device after Activation35.75.8.36.1.4End-device address (DevAddr)31Application ide

15、ntifier (AppEUI)31Network session key (NwkSKey)31Application session key (AppSKey)316.2Over-the-Air Activation326.2.1 End-device identifier (DevEUI)326.2.2 Application key (AppKey)326.2.3 Join procedure326.2.4 Join-request message322016 LoRa AlliancePage 3 of 70The authors reserve the right to chang

16、e specifications without notice.LoRaWAN Specification12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152536.2.5 Join-accept message336.3Activation by Personalization357 Retransmissions back-off36Class B Beacon378 Introduction to Class B389Principle of sync

17、hronous network initiated downlink (Class-B option)391011Uplink frame in Class B mode41Downlink Ping frame format (Class B option)4211.1 Physical frame format4211.2 Unicast & Multicast MAC messages4211.2.1 Unicast MAC message format4211.2.2 Multicast MAC message format4212Beacon acquisition and trac

18、king4312.1 Minimal beacon-less operation time4312.2 Extension of beacon-less operation upon reception4312.3 Minimizing timing drift4313Class B Downlink slot timing4413.1 Definitions4413.2 Slot randomization4514Class B MAC commands4614.414.5PingSlotInfoReq46BeaconFreqReq47PingSlotChannelR

19、eq47BeaconTimingReq48BeaconTimingAns4915Beaconing (Class B option)5015.1 Beacon physical layer5015.1.1 EU 863-870MHz ISM Band5015.1.2 US 902-928MHz ISM Band5015.2 Beacon frame content5115.3 Beacon GwSpecific field format5215.3.1 Gateway GPS coordinate:InfoDesc = 0, 1 or 25315.4 Beaconing precise tim

20、ing5315.5 Network downlink route update requirements5316Class B unicast & multicast downlink channel frequencies5516.1 EU 863-870MHz ISM Band5516.2 US 902-928MHz ISM Band55Class C Continuously listening5617Class C: Continuously listening end-device5717.1 Second receive window duration for Class C571

21、7.2 Class C Multicast downlinks57Support information5918Examples and Application Information6018.4Uplink Timing Diagram for Confirmed Data Messages60Downlink Diagram for Confirmed Data Messages60Downlink Timing for Frame-Pending Messages61Data-Rate Adaptation during Message Retransmissio

22、ns62Recommendation on contract to be provided to the network server by the end-19device provider at the time of provisioning642021Recommendation on finding the locally used channels65Revisions6621.1 Revision 1.06621.2 Revision 1.0.1662016 LoRa AlliancePage 4 of 70The authors reserve the right to cha

23、nge specifications without notice.LoRaWAN Specification12345621.3 Revision 1.0.2662223Glossary67Bibliography6823.1 References6824NOTICE OF USE AND DISCLOSURE69TablesTable 1: MAC message types15Table 2: Major list15Table 3: FPort list20Table 4: MAC commands22Table 5: Channel state table23Table 6: Lin

24、kADRAns status bits signification24Table 7: RX2SetupAns status bits signification26Table 8: Battery level decoding26Table 9: NewChannelAns status bits signification28Table 10: DlChannelAns status bits signification29Table 11: Del mapping table29Table 11: Beacon timing447891011121314151617181920Figur

25、esFigure 1: LoRaWAN Classes8Figure 2: Uplink PHY structure11Figure 3: Downlink PHY structure11Figure 4: End-device receive slot timing12Figure 5: Radio PHY structure (CRC* is only available on uplink messages)14Figure 6: PHY payload structure14Figure 7: MAC payload structure14Figure 8: Frame header

26、structure14Figure 9: LoRa message format elements14Figure 10: Beacon reception slot and ping slots40Figure 11 : beacon-less temporary operation43Figure 12: Beacon timing44Figure 13: Class C end-device reception slot timing57Figure 14: Uplink timing diagram for confirmed data messages60Figure 15: Dow

27、nlink timing diagram for confirmed data messages61Figure 16: Downlink timing diagram for frame-pending messages, example 161Figure 17: Downlink timing diagram for frame-pending messages, example 262Figure 18: Downlink timing diagram for frame-pending messages, example 3622122232425262728293031323334

28、3536373839402016 LoRa AlliancePage 5 of 70The authors reserve the right to change specifications without notice.LoRaWAN Specification1Introduction123456789101112131415161718192021222324252627282930This document describes the LoRaWAN network protocol which is optimized for battery- powered end-device

29、s that may be either mobile or mounted at a fixed location.LoRaWAN networks typically are laid out in a star-of-stars topology in which gateways1 relay messages between end-devices2 and a central network server at the backend. Gateways are connected to the network server via standard IP connections

30、while end- devices use single-hop LoRa or FSK communication to one or many gateways.3 All communication is generally bi-directional, although uplink communication from an end- device to the network server is expected to be the predominant traffic.Communication between end-devices and gateways is spr

31、ead out on different frequency channels and data rates. The selection of the data rate is a trade-off betweencommunication range and message duration, communications with different data ratesdonot interfere with each other. LoRa data rates range from 0.3 kbps to 50 kbps. To maximizeboth battery life

32、 of the end-devices and overall network capacity, the LoRanetworkinfrastructure can manage the data rate and RF output for each end-device individually by means of an adaptive data rate (ADR) scheme.End-devices may transmit on any channel available at any time, using any available data rate, as long

33、 as the following rules are respected:The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences.The end-device respects the maximum transmit duty cycle relative to the sub-band used and local regu

34、lations.The end-device respects the maximum transmit duration (or dwell time) relative to the sub-band used and local regulations.While this document specifies the protocol details, various operational parameters that are based on the regional regulations, such as maximum transmit duty-cycle and dwe

35、ll time persub-band, are described in a separate document (LoRaWAN RegionalParametersPARAMS). This document separation allows addition ofnew regional parameters without having to modify the base protocol specification.1.1LoRaWAN ClassesAll LoRaWAN devices implement at least the Class A functionality

36、 as described in this document. In addition they may implement options named Class B, Class C as also described in this document or others to be defined. In all cases, they must remain compatible with Class A.31323334351 Gateways are also known as concentrators or base stations.2 End-devices are als

37、o known as motes.3 Support for intermediate elements repeaters is not described in the document, however payload restrictions for encapsulation overhead are included in this specification. A repeater is defined as using LoRaWAN as its backhaul mechanism.2016 LoRa AlliancePage 6 of 70The authors rese

38、rve the right to change specifications without notice.LoRaWAN Specification1.2ConventionsMAC commands are written LinkCheckReq, bits and bit fields are written FRMPayload, constants are written RECEIVE_DELAY1, variables are written N.In this document,1234567The octet order for all multi-octet fields

39、 is little endian andEUI are 8 bytes multi-octet fields and are transmitted as little endian. By default, RFU bits are set to zero2016 LoRa AlliancePage 7 of 70The authors reserve the right to change specifications without notice.LoRaWAN Specification2Introduction on LoRaWAN1234LoRa is a wireless mo

40、dulation for long-range low-power low-data-rateapplicationsdeveloped by Semtech.Devices implementing more than Class A are generallyhigher Class end-devices in this d2.1LoRaWAN ClassesA LoRa network distinguishes between a basic LoRaWAN (named Class A) and optional features (Class B, Cl

41、ass C ):567ApplicationMACMAC optionsModulationRegional ISM band8910111213141516171819202122232425262728Figure 1: LoRaWAN ClassesBi-directional end-devices (Class A): End-devices of Class A allow forbi-directional communications whereby each end-devices uplink transmission is followed by two short do

42、wnlink receive windows. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). This Class A operation is the lowest power end-device system for applications that only require downlinkcomm

43、unication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink.Bi-directional end-devices with scheduled receive slots (Class B): End-devices of Class B allow for more

44、 receive slots. In addition to the Class A random receive windows, Class B devices open extra receive windows at scheduled times. In order for the End-device to open it receive window at the scheduled time it receives a time synchronized Beacon from the gateway. This allows the server to know when t

45、he end-device is listening.Bi-directional end-devices with maximal receive slots (Class C): End-devices of Class C have nearly continuously open receive windows, only closed when transmitting. Class C end-device will use more power to operate than Class A or Class B but they offer the lowest latency

46、 for server to end-device communication.2016 LoRa AlliancePage 8 of 70The authors reserve the right to change specifications without notice.LoRa ModulationEU 868EU 433US 915AS 430LoRa MACClass A(baseline)Class B(beacon)Class C(Continuous)ApplicationLoRaWAN Specification2.2 Specification scopeThis Lo

47、RaWAN specification describes the additional functions differentiating an end-device higher Class from one of Class A. A higher Class end-device shall also implement all the functionality described in the LoRaWAN Class A specification.123456782016 LoRa AlliancePage 9 of 70The authors reserve the rig

48、ht to change specifications without notice.NOTE: Physical message format, MAC message format, and other parts of this specification that are common to both end-devices of Class A and higher Classes are described only in the LoRaWAN Class A specification to avoid redundancy.LoRaWAN Specification CLAS

49、S A ALLEND-DEVICESAll LoRaWAN end-devices must implement Class A features.122016 LoRa AlliancePage 10 of 70The authors reserve the right to change specifications without notice.LoRaWAN Specification3Physical Message Formats12The LoRa terminology distinguishes between uplink and downlink messages.3.1

50、 Uplink MessagesUplink messages are sent by end-devices to the network server relayed by one or many gateways.Uplink messages use the LoRa radio packet explicit mode in which the LoRa physical header (PHDR) plus a header CRC (PHDR_CRC) are included.1 The integrity of the payload is protected by a CR

51、C.The PHDR, PHDR_CRC and payload CRC fields are inserted by the radio transceiver.Uplink PHY:34567891011Figure 2: Uplink PHY structure3.2Downlink MessagesEach downlink message is sent by the network server to only one end-device andis relayed by a single gateway.2Downlink messages use the radio pack

52、et explicit mode in which the LoRa physical header (PHDR) and a header CRC (PHDR_CRC) are included.3Downlink PHY:12131415161718Figure 3: Downlink PHY structure3.3Receive WindowsFollowing each uplink transmission the end-device opens two short receive windows. The receive window start times are defin

53、ed using the end of the transmission as a reference.192021221 See the LoRa radio transceiver datasheet for a description of LoRa radio packet implicit/explicit modes.2 This specification does not describe the transmission of multicast messages from a network server to many end-devices.3 No payload i

54、ntegrity check is done at this level to keep messages as short as possible with minimum impact on any duty-cycle limitations of the ISM bands used.2016 LoRa AlliancePage 11 of 70The authors reserve the right to change specifications without notice.PreamblePHDRPHDR_CRCPHYPayloadPreamblePHDRPHDR_CRCPHYPayloadCRCLoRaWAN Specification12Figure 4: End-device receive slot timing.3.3.1First receive window channel, data rate, and start3456789The first receive window RX1 uses a frequency that is a function of the uplink fre