系统梳理与分析：NB-IoT与eMTC的十轮鏖战
伴随移动通信技术的不断发展，全球物联网即将迎来快速的发展。在国际运营商中， AT＆T、Verizon、KDDI、KPN、Orange、NTT DoCoMo、Telefonica、Telstra、Telus都先后开展了eMTC的商用。在我国，电信率先起跑，在确立了800MHz组网能力之后，一口气要建成30万NB－IOT基站。联通与Jasper签订双排他协议，早早确定了NB－IOT作为发展方向。而最早...了解详情
LoRa定位技术
物联网应用对位置的需求越来越多，LoRa技术提供了另一种定位选择LoRa在LPWAN中是独一无二，提供原生免GPS定位技术。LoRa地理位置允许用户定位资产、跟踪设备和检测地理围栏知道某些东西在哪里。这种地理位置功能是LoRaWAN独有的，通过LoRa技术来实现。Machina Research预测，60％的物联网设备将会使用地理位置数据，其中三分之一的应用将严重地依赖于位置。Semtech早期就明确了低功率广域网地理位置的重要性，在地理定位技术方面投入了大量时间和精力，经过了三年多的开发，于2016年6月宣布增加此功能。地理位置有四个主要用处：定位、导航、管理和跟踪。定位：快速识别位置意味着节省时间并提高效率。 例如，通过了解事件的确切位置，用户可以快速做出反应并可能提高安全性。导航：即时的位置信息开启导航功能，帮助确定一个可靠的和有效的路线，并避免延迟和/或拥堵。管理：提供数据的位置关联性有助于增强其价值和实用性。 这对于温度和水位监测特别有用，可以改善自然灾害的反应时间，如火山爆发和洪水。跟踪：LoRa地理位置对跟踪资产和传感器特别有用。 通过访问地理标签的数据，用户可以对偏差做出反应，预测潜在的问题。各种不同的技术都提供了定位解决方案，需要对精度、设备价格、覆盖范围和功耗做个权衡取舍LoRa是唯一无二的，只要终端节点与网络通信，就可以得到地理位置数据。 对物料清单和功耗几乎没有任何影响。 基于LoRa的地理位置可以工作在室外和室内，精度取决于地形和基站密度。我们来看看地理位置的一些典型应用：智慧城市和交通监控：汽车应用中的地理位置功能可用于事故跟踪和通知，以及预测性维护需求。具体位置的数据有助于算法做出更好的预测。计量和物流：地理位置功能在物流中有各种应用。 一些例子包括垃圾桶、回收库、气罐或任何其他任何容器的填充率监测。 数据可用于自动优化收集路线并节省运营成本。 此外，地理位置可用于资产跟踪实现更有效的库存管理。农业：LoRa地理位置目前用于家畜跟踪。 通过跟踪牛并监测它们的健康，例如，你可以更快更容易地照料生病的牛。 在一个大牧场上，了解病畜的具体位置可以明显地提高反应时间。LoRa地理位置还应用在建筑、保险和消费行业等，用于跟踪高价值资产，如建筑材料、保险商品、宠物甚至人等！LoRa地理位置提供最低的功率、成本和环境影响。与地理位置相关的接收、传输或处理在传感器外面完成，因此不需要额外的硬件、电池或时间。介绍LoRa定位技术继续介绍LoRa地理位置，让我们来快速看一下基础的技术。目前，LoRa使用到达时间差（Time Difference of Arrival，TDOA）来实现地理定位。 要了解它是如何工作的，我们来看看从终端节点到服务器的数据传输步骤。开始，所有的基站或网关共享一个共同的时基，这是重要的。当任何LoRaWAN设备发送一个数据包时，该数据包被范围内的所有网关接收，并且每个报文都将报告给服务器。所有的网关都是一样的，它们一直在所有信道上接收所有数据速率的信号。 这意味着终端设备上没有开销，因为它们不必扫描和连接到特定的网关。 传感器简单地唤醒，发送数据包，范围内的所有网关都可以接收它。然后，所有网关都会将相同的数据包发回到服务器，使用内置在最新一代网关中的专用硬件和软件捕获高精度到达时间。 接下来，服务器端的算法比较到达时间、信号强度、信噪比和其他参数来计算终端节点的最可能位置。未来，我们期待混合数据融合技术和地图匹配增强来改善到达时间差，提高定位精度。为了使地理位置准确地工作，需要通过至少三个网关接收到数据包。更多网关的更密集网络会提高定位的精度和容量。这是因为当更多的网关接收到相同的数据包时，服务器算法会收到更多的信息，从而提高了地理位置精度。现在，我们来讨论一下硬件。 网关内部需要下一代的硬件来计算地理位置中使用的一些参数，如高精度的到达时间。Semtech于2016年初创建了网关参考设计，此后在许多网关中成功实现。 它包括了所需的高质量时间戳功能，并且适用于获得授权的网关合作伙伴。 这样确保了多个供应商的部署都能一致地工作，提供高质量的时间戳，从而实现最高质量的地理定位服务。需要重点注意的是，地理位置完全依靠网关和网络技术，因此一旦网关升级，地理位置功能就可用于所有设备。Semtech还提供了一个地理位置解算程序。通用的解算程序不是专用的应用程序，是与终端节点无关的，为LoRa地理定位服务提供了良好的起点。 另外，定义了一个API，允许系统集成商使用第三方可能提高可用位置精度的解算算法。通过这种开放的模式，Semtech鼓励解算技术的创新和发展，确保基于LoRaWAN的地理位置不断改进。当数据包到达网关时，它不知道数据包来自哪个终端设备。因此，网关给接每个接受到的数据包加上时间戳，并将其转发给服务器。由于访问地理位置服务是有价值的，所以这些时间戳在网关中通过加密来保护。时间戳被传输到网络服务器，Semtech授权解密功能给网络服务提供商。 网络服务器提供商可以根据订阅的服务级别对数据进行解密。要提供良好位置最大困难之一是减少多路径传输。如上图所示，一些数据包直接去了网关，有些数据包并没有但有一个反射信号，其他数据包两种情况都有。使用更多数据包传输来减少多路径传输，可以通过更多的信道、更多的网关、更多天线以及使用机器学习或统计技术。最后，我们来看看数据的可控参数。频率分集。通过在所有可用信道上重复发送一条消息，平均来看地理位置结果有50％的改善。 一个工作在8通道网络上的静态终端节点在8个不同信道上发送8个数据包后，那么其结果将提高50％。部署网关网格的形状。 网关部署网格的影响约为25％。 一个长的细网格将比一个方格网格差25％。 因此，网络部署应尽可能侧重于以方形模式部署网关。网关分集。 一般来说，接收信号的网关越多，结果越准确。 然而，超过6个网关，地理位置改善开始变得不明显。 3到4个网关，大概有25％的改善，超过4个网关地理位置改善开始减少。最后，天线分集。 天线分集对最弱的信号影响最大。因此，如果设备在3个网关上处于接收良好的位置，增加一个弱的第四个网关，天线分集通常会改变在第四个网关上接收到的数据包从不可用到可用。在这种情况下，它可以提供25％的地理位置改善。了解详情
LoRaWAN的起源和网络架构
作者：王志杰 来源芯资讯LoRaWAN的起源LoRaWAN缘何而来？都解决了什么问题？LoRaWAN是一种低功耗广域网规范，基于MAC层定义，面向物联网应用。该规范主要使用LoRa调制解调支持大多数的物联网应用。Semtech、Actility和IBM Research在苏黎共同制定了物联网的规范。自2014年以来，这几家公司合作设计了LoRaMAC，一个解决了物联网市场安全、能源效率、漫游和配置入网（onboarding）挑战的规范。2015年2月，LoRa联盟成立于巴塞罗那移动世界大会。 LoRaMAC被重新命名为“LoRaWAN”，成为LoRa联盟成员的规范。所有成员现在通过联盟技术委员会对本规范作出贡献。LoRaWAN 1.0规范可以从LoRa联盟网站下载，www.lora-alliance.orgLoRaWAN规范解决了广阔的物联网市场所带来的挑战，其特性包括：双向性：任何的LPWA技术提供完全双向通信是关键的；任何设备都能够向网络报告（称为UpLink消息），还可以由网络（称为DownLink消息）来控制。 这在许多方面是有意义的，例如设备的配置入网（onboarding）、网络管理和许多需要用到应答（Acknowledgement ）或设备执行机构的其他应用。安全性：分析师预估到2020年将会有数十亿的连接设备，保护物联网用户的安全是至关重要的。 LoRaWAN使用与金融行业类似的智能密钥生成机制，提供数据认证以及端到端有效载荷的加密。易于调试：如果今后要将数十亿台设备连接到网络，其配置入网（on‐boarding）的过程应该是无缝的，不需要考虑SIM卡的分发。地理定位：许多物联网应用需要设备位置跟踪。 LoRaWAN使用免GPS的地理定位功能，以合理的成本无缝地规划网络内外的设备漫游。可扩展性：这也是关键。可从数千的终端设备开始部署新的网络；但是，当需要更大容量时，可以增加基础设施最终连接数百万甚至数十亿个终端设备。标准化：通过LoRa联盟，广泛的生态系统合作伙伴都使用相同的标准来创建网络。最新版本的LoRaWAN可以从LoRaAlliance网站www.lora-alliance.org下载。关于LoRaWAN网络架构LoRaWAN网络架构图终端节点在上面的LoRaWAN网络架构图中，终端节点是在最左边，异步地广播数据包到网络。 遵循Aloha网络规范，保证终端设备可以将大部分时间处于空闲模式，功耗少于1uA。 这种方法可确保在小型电池上的应用可以实现10至15年的使用寿命。因为低功耗，LoRaWAN网络是Aloha介质访问网络规范最适合的技术选择，广域网络主要工作在ISM频段。 在免授权频段中，介质质量和可访问性不能被保证，这意味着任何类型的时隙多址技术都将会面临信道可用性问题。 时分多址，需要设备同步，可能会在终端设备上造成很大的成本，并且与LPWA中的一些用例不兼容。集中器/网关通过终端节点广播的数据包将会被网络中的一个或多个网关接受到。网关有一个多信道和多数据速率的射频嵌入式设备，可以扫描和检测任意活动信道上的数据包并对其进行解调。网关是到核心网络简单的通信通道，而且它们通常没有内置的智能处理。 这有两个主要优点：网关是由非常简单的、便宜的硬件组成不需要从单元到单元的漫游。 终端节点广播其数据包，不需要考虑哪个网关会接收它们，并且多个网关可以接收数据包，而对其能量消耗没有任何的影响。 不需要切换过程或同步。回程网关通常需要一个以太网的回程。不过，目前的一些部署使用了2G、3G或4G作为回程。 例如，在LoRaWAN生态圈里的一些公司还提出了一种替代的解决方案，在没有蜂窝网络信号覆盖的地方，使用了卫星作为回程。网络服务器核心网络是LoRaWAN系统的重要部分。 它承载所有需需的智能来管理网络并将数据分发到其他服务器。 一些功能包括：消息合并：来自多个网关相同数据包的多个副本被转发到网络服务器。 网络服务器记录这些数据包，分析数据包的接收质量，并通知网络控制器。路由：对于下行链路，网络服务器决定到终端节点的最佳路由。 通常，这个决定是基于先前传送数据包的链路质量指示，从接受的信号强度指示（Received Signal Strength Indication，RSSI）和信噪比（Signal to Noise Ratio，SNR）计算出来。网络控制：链路质量还有助于为某个终端节点决定最相关的通信速度或扩频因子。 这就是我们所说的ADR（Adaptive Data Rate），或自适应数据速率策略，这由网络控制器来处理。网络和网关监控：网关通常通过加密的IP链路连接到网络服务器。 网络通常包含网关管理和监控接口，允许网络提供商管理网关，处理故障情况，监控告警和其他一些功能。此外，核心网络还与其他服务器进行通信，组织漫游，连接到客户的应用服务器等等。应用服务器LoRaWAN协议支持不同类型的网络。 一些网络提供商也是应用提供商。 因此，在LoRaWAN网络架构图图中最右侧的应用服务器可以与网络服务器分别托管或与网络服务器集成在一起托管。LoRaWAN的配置入网（on‐boarding，或称为设备上载）方案已准备好支持这种“多租户网络”场景，许多不同的应用供应商提供了异构的应用。了解详情
LoRaWAN相比LoRa私有协议应用的优势
很多应用用上了LoRa技术的芯片，但没有使用LoRaWAN网络协议。有些是因为应用点数少、规模小，用LoRaWAN网络成本高。有些是因为LoRaWAN技术门槛高，短期掌握不了，遂退而求其次。但是，在未来随着物联网的规模不断扩大、应用越来越广泛，接入的监测点和控制点越来越多，使用LoRaWAN将是大势所趋。LoRa是物理层传输技术，典型特点是距离远、功耗低。速率相对较低。LoRa对应的产品就是收发器...了解详情
深入解析8大关键技术，4大应用场景，看完秒懂5G
未来的网络将会面对：1000倍的数据容量增长，10到100倍的无线设备连接，10到100倍的用户速率需求，10倍长的电池续航时间需求等等。坦白的讲，4G网络无法满足这些需求，所以5G就必须登场。但是，5G不是一次革命。5G是4G的延续，我相信5G在核心网部分不会有太大的变动，5G的关键技术集中在无线部分。虽然5G最终将采用何种技术，目前还没有定论。不过，综合各大高端论坛讨论的焦点，我今天收集了8大...了解详情
自制你的LoRa设备（英文：Building your LoRa devices）
IntroductioThis page describes how to build LoRa end-devices. We mostly focus on Arduino platforms ( and describe how to connect and use various LoRa radio module: Libelium LoRa, HopeRF RFM92W/RFM95W...了解详情
DIY自制低成本LoRa网关（英文：A DIY low-cost LoRa gateway）
1. IntroductioThis page describes our low-cosLoRagateway based on a Raspberry PI. The gateway can receive from any LoRa device and is designed to be fully customizable for a targeted application with post-processing features based on high-level languages such as python. Typical post-processing features are to push the received data on various IoT/cloud platforms. Currently, we provide example for DropBoxTM, FirebaseTM, ThingSpeakTM, SensorCloudTM, GroveStreamsTM, FIWARE.The work presented here is part of the EU H2020 WAZIUP project (grant agreement number 687607, 2016-2019) which objective is to develop low-cost IoT solutions for deployment in sub-saharian African countries. Various applications are considered: water quality monitoring, cattle rustling, logistics and goods transportation. More details will come soon, but right now you can get the presentation of the developped gateway in.pdf.There are many advanced and well-integrated LoRa gateways capable of simultaneous reception on several channels and implementing the LoRaWAN specification (see slides). These gateways are based on the SX1301 baseband concentrator. Our LoRa gateway could be qualified as “single connection” as it uses the SX1272, much like an end-device would do. However, in order to increase LoRa transmission robutsness we improve the LoRa transmission with CSMA features (or so-called Listen Before Talk) and add Quality of Service guarantees with regards to radio time limitations. This solution keeps the cost of the gateway low and can satisfy small to medium size deployment scenario for ad-hoc application cases in various private usages, farming, agriculture, infrastructure surveillance, application-specific telemetry systems,… Note that more than 1 gateway can be deployed to serve several channel settings. However, it is probably not adapted, in the current state of development, to large-scale deployment with a large number of end customers from various different organizations with their own and different requirements regarding data management, confidentiality and security.Download:github(drop me a mail if you use our development so that we could advertise it)gw_full_latest folder: the latest version of the gateway softwarethe modified SX1272 library (initial version comes from Libelium) with enhanced features: support of SX1276, LBT & CSMA-like, …the arduPi library for RPI1 and RPI2the lora_gateway.cpp code (which compile on both RPI and Arduino)the makefilethe post-processing python scripts: cloud management, encryption, etc.Arduino folderthe modified SX1272 library (initial version comes from Libelium) with enhanced features: support of SX1276, LBT & CSMA-like, …the lora_gateway.ino code (which compile on both RPI and Arduino)an interactive end-device sketchvarious templates for most of Arduino boards (Uno, Mega, Due, Pro Mini, Teensy, etc.). Work out-of-the box with the gateway.a README.md for some installation/compilation instructionsourFAQ, explaining our LoRa framework, and especially why we are not LoRaWAN compatibleDownload:full SD card zipped imagefor the Raspberry gateway (based on Raspbian Jessie)Supports Raspberry 1B+, RPI2 and RPI3.Get the zipped image, unzip it, install it on an 8GB SD card, seethis tutorial from www.raspberrypi.orgPlug the SD card into your RaspberryConnect a radio module (see below)Power-on the RaspberryThe LoRa gateway starts automatically when RPI is powered onWith an RPI3, the Raspberry will automatically act as a WiFi access point. For RPI 1&2, see instructions on githubUpdate to the latest gateway version:https://github.com/CongducPham/LowCostLoRaGw#latest-gateway-versionBy default, incoming data are uploaded to ourLoRa ThingSpeak test channelWorks out-of-the-box with theArduino_LoRa_Simple_temp sketch2. Hardware componentsThe gateway is based on a Raspberry PI. RPI 1B+/2B/3B can be used. The LoRa modules comes from (a) Libelium LoRa radio module, (b) HopeRF RFM92W/HopeRF RFM95W (or RFM96W for 433MHz), (c) Modtronix inAir9/inAir9B (or inAir4 for 433MHz), (d) NiceRF LoRa1276. Libelium LoRa and RFM92W use the Semtech SX1272 chip while RFM95W, inAir9/9B and NiceRF LoRa1276 use the SX1276 which is actually more versatile.Figure: supported (tested) radio modulesFigure: Left: Hardware components with a Modtronix inAir9 radio module. Right: RPI GPIO header for RPI 1B (short) and RPI 2B/3B (long)Figure:GPIO header of the RPIUsing Libelium LoraFor the Libelium LoRa module, we directly connected the LoRa module without the connection bridge developed by Libelium to save the extra cost of the connection bridge, by just connecting the required SPI pins (MISO, MOSI, SPI_CLK and SPI_nSSEL), VCC and GND to the corresponding pins on the RPI (CE0 on the RPI for SPI_nSSEL and 3v3 for VCC). Pin out diagrams for the LoRa module in XBee format is shown below. The LoRa module from Libelium is however quite expensive: around 45€.Figure: XBee pin-out diagram for the Libelium LoRa moduleWe solder the wires to the pin as shown in the figure below. If the RPI is put in a case for outdoor usage, the radio module could just be fixed with the antenna or an SMA extension cable could be used. At the Raspberry side, you can simply plug the right cable end to the corresponding GPIO pin.Figure: using two 10-pin 2mm female socket to connect the LoRa module that has an XBee format. Right: the module is seen from the back sideFigure: connect the LoRa radio module to the RPI GPIO headerUsing HopeRF RFM92W/RFM95WNow, the HopeRF RFM92W (RFM95W) module is shown below. An adapter is need to have the break-out pins (the RFM92W module is quite small) and most importantly the antenna plug (which is in Female SMA). Note that the latest news from HopeRF indicated that the RFM92W is discontinued because the RFM95W is better. So you probably will have an RFM95W if you buy them now.Figure: the RFM92W module (left), the RFM92W adapter (middle), the RFM92W and the adapter before soldering, comparison with the Libelium LoRa for size (right)After some delicate soldering, we have the RFM92W module ready to be plugged on our Raspberry like previously: just connect the right cable to the GPIO header or use an additional header for fast insertion/removal of the radio module.Figure: the RFM92W and the adapter, after soldering (left), ready to be plugged on the Raspberry (middle), the adapter pin-out (right)The RFM92W (or RFM95W) with the adapter costs less than half of the Libelium LoRa (around 15€) which makes it quite attractive for our low-cost LoRa gateway. As both use the native SPI communication with the SX1272, the Libelium library can also drive the RFM92W, as explained in next section. See our low-cost gateway based on the RFM92W/95W at the end of the page.Using Modtronix inAir9We also tested with the Modtronix inAir9 which is based on the SX1276. This module has 2 advantages: it costs less than half of the Libelium LoRa (around 15€) and can come with the header pins already soldered! The left figure shows the radio module and the right figure shows the pin out.To connect the inAir to the Raspberry, proceed as previously: just connect the right cable to the GPIO header or use an additional header for fast insertion/removal of the radio module. Our first tests show that the inAir is reliable. Given its low cost and readiness (the RFM92W/RFM95W need some soldering) it is definitely a good choice. Note that there is an inAir9B with +20dBm transmit power but regulation is quite strict on such transmit power usage.Using the LoRa GPS HatTheLoRa GPS Hat from Draginois also a nice solution based on an RFM95W. Look at theDragino wikithat explain how to use their shield with our library (see example 4).Important notice for the SX1272 libraryNote that the original Libelium library to drive the LoRa module does not use DIO pins as many other libraries do, so there is no need to connect these pins. You can use other development codes using DIO pins by connecting the required pins that are mostly configured as follows DIO0 (RXdone or TX done), DIO1 (RX timeout) and DIO5 (ready). Of company, you have to check first. Some may also use the RST pin to reset the module.3. Main architectureInitially, the gateway was implemented on an Arduino (MEGA/Due) for test purpose and for having a “direct” transparent radio bridge. We enhanced the gateway code but maintained compatibility with Arduino therefore the main features are available on both platforms. On the RPI, we use the arduPI layer provided by Libelium to run both the SX1272 library and the gateway program. The original SX1272 library has been significantly improved to support also the SX1276, to add CSMA-like capability to increase LoRa efficiency and implement the possibility to dynamically ask for an ACK from the receiver side. This library basically drives the SX1272 through the SPI interface (it then works with no modifications with the HopeRF RFM92W and has some modifications for the SX1276). The most important point to mention is that the original library adds 5 bytes for internal usage as shown is the following figure, taken from the Libelium documentation.| dst addr (1 byte | src addr (1 byte | sequence number (1 byte | payload length (1 bytes | payload data (variable length | retry counter (1 byte |
LoRaWAN协议中文版 第17章 Class C – 持续接收的终端
前言这是《LoRaWAN102》的译文，即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。我正在陆续对协议的各个章节进行翻译，具体其他章节的译文，以及译文之外的代码解析，可点此查看帖子LoRa学习笔记_汇总。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/翻译开始第17章 持续接收的终端具备Class C 能力的终端，通常应用于供电充足的场景，因此不必精简接收时间。Class C 的终端不能执行 Class B 。Class C 终端会尽可能地使用 RX2 窗口来监听。按照 Class A 的规定，终端是在 RX1 无数据收发才进行 RX2 接收。为了满足这个规定，终端会在上行发送结束和 RX1 接收窗口开启之间，打开一个短暂的 RX2 窗口，一旦 RX1 接收窗口关闭，终端会立即切换到 RX2 接收状态； RX2 接收窗口会程序打开，除非终端需要发送其他消息。注意：没有规定节点必须要告诉服务端它是 Class C 节点。这完全取决于服务端的应用程序，它们可以在 join 流程通过协议交互来获知是否是 Class C 节点。17.1 Class C 的第二接收窗口持续时间Class C 设备执行和 Class A 一样的两个接收窗口，但它们没有关闭 RX2 ，除非他们需要再次发送数据。因此它们几乎可以在任意时间用 RX2 来接收下行消息，包括MAC命令和ACK传输的下行消息。另外在发送结束和 RX1 开启之间还打开了一个短暂的RX2窗口。图13.Class C 终端的接收时隙时序图17.2 Class C 对多播下行的处理和 Class B 类似，Class C 设备也可以接收多播下行帧。多播地址和相关的 NWKSKEY 及 APPSKEY 都需要从应用层获取。Class C 多播下行帧也有相同的限制：不允许携带MAC命令，既不能放在FOpts域中，也不能放在 port 0 的 payload 中，因为多播下行无法像单播帧那样具备相同的鲁棒性。ACK 和 ADRACKReq 位必须要为0。MType 域需要为 Unconfirmed Data Down 类型的数值。FPending 位表明有更多的多播数据要发送。考虑到 Classs C 设备在大部分时间处于接收状态，FPending位不触发终端的任何特殊行为。翻译完了解详情
LoRaWAN协议中文版 第2章 LoRaWAN Classes 类型介绍
前言这是《LoRaWAN102》的译文，即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。我正在陆续对协议的各个章节进行翻译，具体其他章节的译文，以及译文之外的代码解析，可点此查看帖子LoRa学习笔记_汇总。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/翻译开始第2章 LoRaWAN Classes 类型介绍LoRa 是由Semtech面向长距离、低功耗、低速率应用而开发的无线调制技术。本文档中，将 Class A 基础上实现了更多功能的设备称为“更高 class 终端”。2.1 LoRaWAN ClassesLoRa网络包含基础LoRaWAN（称之为Class A）和可选功能（Class B，Class C）:图1.LoRaWAN Classes双向传输终端(Class A)： Class A 的终端在每次上行后都会紧跟两个短暂的下行接收窗口，以此实现双向传输。传输时隙是由终端在有传输需要时安排，附加一定的随机延时(即ALOHA协议)。这种Class A 操作是最省电的，要求应用在终端上行传输后的很短时间内进行服务器的下行传输。服务器在其他任何时间进行的下行传输都得等终端的下一次上行。划定接收时隙的双向传输终端(Class B)： Class B 的终端会有更多的接收时隙。除了Class A 的随机接收窗口，Class B 设备还会在指定时间打开别的接收窗口。为了让终端可以在指定时间打开接收窗口，终端需要从网关接收时间同步的信标 Beacon。这使得服务器可以知道终端正在监听。最大化接收时隙的双向传输终端(Class C)： Class C 的终端基本是一直打开着接收窗口，只在发送时短暂关闭。Class C 的终端会比 Class A 和 Class B更加耗电，但同时从服务器下发给终端的时延也是最短的。2.2 文档范围这份LoRaWAN协议还描述了与 Class A 不同的其他 Class 的额外功能。更高 Class 的终端必须满足 Class A 定义的所有功能。注意：物理层帧格式，MAC帧格式，以及协议中更高 class 和 Class A 相同的内容都写在了 Class A 部分，避免内容重复。翻译完了解详情
LoRaWAN协议中文版 第1章 介绍
前言这是《LoRaWAN102》的译文，即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。我正在陆续对协议的各个章节进行翻译，具体其他章节的译文，以及译文之外的代码解析，可点此查看帖子LoRa学习笔记_汇总。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/翻译开始第1章 介绍本文档描述了LoRaWAN网络协议，是针对电池供电的终端设备(不管移动还是固定位置)进行优化的一套网络协议。LoRaWAN网络通常采用星型拓扑结构，由拓扑中的网关来转发终端与后台网络服务器间的消息。网关通过标准IP连接来接入网络服务器，而终端则通过单跳的 LoRa 或者 FSK 来和一个或多个网关通讯。虽然主要传输方式是终端上行传输给网络服务器，但所有的传输通常都是双向的。终端和网关间的通讯被分散到不同的信道频点和数据速率上。数据速率的选择需要权衡距离和消息时长两个因素，使用不同数据速率的设备互不影响。LoRa的数据速率范围可以从 0.3kbps 到 50kbps。为了最大程度地延长终端的电池寿命和扩大网络容量，LoRa网络使用速率自适应(ADR)机制来独立管理每个终端的速率和RF输出。虽然每个设备可以在任意信道，任意时间，发送任意数据，但需要注意遵守如下规定：终端的每次传输都使用伪随机方式来改变信道。频率的多变使得系统具有更强的抗干扰能力。终端要遵守相应频段和本地区的无线电规定中的发射占空比要求。终端要遵守相应频段和本地区的无线电规定中的发射时长要求。twowinter注：发射占空比，意思是发射时长占总时长的比例。按照无线电规定，每个设备不能疯狂发射霸占信道，总得给别人一点机会。这份文档主要讲述协议细节，一些基于各地区规定的操作参数，例如发射占空比和发射时长等，在另一份文档[LoRaWAN地区参数]中做具体描述。将这份文档分开，是为了加入新地区参数时不影响基础的协议规范。1.1 LoRaWAN Classes所有的LoRaWAN设备都必须至少实现本文档描述的 Class A 功能。另外也可以实现本文档中描述的 Class B 和 Class C 及后续将定义的可选功能。不管怎么样，设备都必须兼容 Class A。1.2 文档约定MAC命令的格式写作 LinkCheckReq (粗斜体)，位和位域的格式写作 FRMPayload (粗体)，常量的格式写作 RECEIVE_DELAY1，变量的格式写作 N。在本文档中，所有多字节字段的字节序均采用小端模式EUI 是8字节字段，采用小端模式传输默认所有RFU保留位都设为0翻译完了解详情
LoRaWAN协议中文版 第3章 PHY帧格式
前言这是《LoRaWAN102》的译文，即LoRaWAN协议规范 V1.0.2 版本( 2016 年 7 月定稿)。我正在陆续对协议的各个章节进行翻译，具体其他章节的译文，以及译文之外的代码解析，可点此查看帖子LoRa学习笔记_汇总。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/翻译开始第3章 PHY 帧格式LoRa 有上行消息和下行消息。3.1 上行消息上行消息是由终端发出，经过一个或多个网关转发给网络服务器。上行消息使用 LoRa 射频帧的严格模式，消息中含有 PHDR 和 PHDR_CRC 。载荷有CRC校验来保证完整性。PHDR，PHDR_CRC 及载荷 CRC 域都通过射频收发器加入。上行 PHY:| Preambl | PHD | PHDR_CR | PHYPayloa | CR |
| Preambl | PHD | PHDR_CR | PHYPayloa |
LoRaWAN协议V1.0.2中文版_配套文件 地区参数(物理层)
前言这是《LoRaWAN102》的配套文档《LoRaWAN_Regional_Parameters_v1_0》(2016年7月定稿)的中文译文，在早期的LoRaWAN协议中它是以第7章 物理层的形式存在，由于LoRaWAN逐步应用过程中肯定会有很多新区域加进来，为了不影响旧有协议文档主体，所以从V1.0.2版本开始，联盟把这块内容单独出来。该LoRaWAN官方源文件可点此下载。我正在陆续对协议的各个章节进行翻译，具体其他章节的译文，以及译文之外的代码解析，可点此查看帖子LoRa学习笔记_汇总。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/翻译开始LoRaWAN地区参数1 介绍这份文档描述了全球不同地区的LoRaWAN具体参数。这份文档是对LoRaWAN协议文档(从版本V1.0.2开始)的配套补充文档。为了避免新区域的加入而导致文档的变动，因此将地区参数章节从协议规范中剥离出来。2 LoRaWAN地区参数2.1 欧洲 863-870MHz 免授权频段待补充，计划3月份补足。2.2 美国 902-928MHz 免授权频段待补充，计划3月份补足。2.3 中国 779-787MHz 免授权频段待补充，计划3月份补足。2.4 欧洲 433MHz 免授权频段待补充2.5 澳洲 915-928MHz 免授权频段待补充2.6 中国 470-510MHz 频段2.6.1 中国 470-510MHz 前导码格式要用如下的同步字：| 调制方式 | 同步字 | 前导码长度 |
| LoR... |
LoRaWAN协议解析 第6章 终端激活
1 前言我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析，可点此查看帖子LoRa学习笔记_汇总。欢迎同行朋友们留言交流。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/2 梳理解析LoRaWAN第6章，主要对节点加网做了描述，它有两种方式。如果要用一句话来总结的话，那就是这一句了，请看：如果是空中激活，则需要准备 DevEUI，AppEUI，AppKey 这三个参数，即设备自身MAC地址和要使用的应用(应用ID和密钥)。如果是ABP激活，则直接配置 DevAddr，NwkSKey，AppSKey 这三个LoRaWAN最终通讯的参数，不再需要join流程。在这种情况下，这个设备是可以直接发应用数据的。这里插个题外话，商用的LoRaWAN网络一般都是走OTAA流程，这样安全性才得以保证。(twowinter，你数数，这是一句话?)(如果是空中激活，则需要准备 DevEUI，AppEUI，AppKey来join。如果是ABP激活，则直接配置 DevAddr，NwkSKey，AppSKey。)3 代码位置3.1 激活处理协议的第6章，相关的核心代码是这么几行，位于 \src\mac\main.c。整个代码结构非常清晰，用一个宏(OVER_THE_AIR_ACTIVATION)分开两段，分别对应两种激活方式。3.2 参数配置关于参数部分，相关的默认值全部位于\src\apps\LoRaMac\classA\硬件平台\Comissioning.h本尊有机会接触了几个LoRaWAN基站厂家，发现大家为了调试方便，一般也会支持这些默认值。End了解详情
LoRaWAN协议解析 第5章 MAC命令
1 前言我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析，可点此查看帖子LoRa学习笔记_汇总。欢迎同行朋友们留言交流。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/2 梳理解析从LoRaWAN第4章的帧格式可以得到如下信息：MAC命令，要么使用FPort0来单独传输，要么使用非零的FPort来和数据一起传输。LoRaWAN第5章，LoRaWAN出于网络管理需要，提出了9条MAC命令，这个章节是对9条命令进行具体的描述。说个题外话，CLAA(中国LoRa应用联盟)在9条命令以外还扩充了一些MAC命令。现阶段协议还不能公开，所以我就不多说了。中兴目前作为LoRa联盟董事会成员，也许以后会把这些拓展MAC命令引入到LoRaWAN协议也说不准，大家暂且当个课外知识了解下就好。3 代码位置MAC命令枚举MAC命令的接收处理OnRadioRxDone()携带着MAC帧进来，经过层层筛选，最终到达ProcessMacCommands()来处理MAC命令。这里代码中涉及的两种处理方式，可以跟协议对应起来：port = 0时，MAC命令放在FRMPayload中，需要先解密再处理；port非零时，MAC命令放在fopts中。MAC命令的发送及回复MAC命令的发送及回复处理都在这个函数中，AddMacCommand()。协议栈对MAC命令发送的处理还是比较简单的，都是放在Fopts中来传输，都在这个15字节的MacCommandsBuffer中。了解详情
LoRaWAN协议解析 第4章 MAC帧格式
1 前言我正在陆续对《LoRaWAN102》即LoRaWAN协议规范 V1.0.2 版本(2016年7月定稿)协议的各个章节进行翻译。译文之外还对LoRaWAN协议和源码进行了解析，可点此查看帖子LoRa学习笔记_汇总。欢迎同行朋友们留言交流。本文作者twowinter，转载请注明作者：http://blog.csdn.net/iotisan/2 梳理解析LoRaWAN第4章，主要讲述了MAC帧格式，对所有涉及的字段都做了解释。千言万语汇成一句话，哦不，汇成一个表。| 数据帧头 | DevAdd | FCtr | FCn | FOpt | ||||||||
| 数据帧 | Preambl | PHD | PHDR_CR | MHD | FHD | FPor | FRMPayloa | MI | CR | |||
| MAC层 | Preambl | PHD | PHDR_CR | MHD... | ||||||||
用于物联网无线传感器网络的低功耗长距离无线技术
作者：European Editors 来源：Digi-Ke低功耗广域网 (LPWAN) 已出现很长时间，但对物联网 (IoT) 低成本连接及功耗和成本改进的需求正引发对 LPWAN 越来越多的关注。 硅技术的改进已极大降低了功耗，可用于电池供电型无线传感器节点。 这些节点利用次 GHz 非调节式无线电频段进行长距离连接，比调节式蜂窝频带更具成本效益。然而，推广这些 LPWAN 网络需要其自身的...了解详情