KPN Internet of Things Community
IoT News, Information, Questions, Answers & Solutions
- 576 Topics
- 0 Reacties
Receive LoRa data
My question is about receiving LoRa data packets. I already configured packets which are sent from an Arduino program and are visible in the kpn devicemanager and wlogger. I just read an 11 months old topic about an Application data API but got No response with the provided URL (and using my own DevEUI). Does anyone know how to fetch your LoRa packets or what I am doing wrong related to the other topic? (https://zakelijkforum.kpn.com/lora-forum-16/application-data-api-4768#_=_ )
LoRa | Dictionary & Definitions
[b]ABP [/b] - Activation By Personalization [b]ADR[/b] - Adaptive Data Rate. ADR is used to optimize data rates, air time and energy consumption. ADR is set (on/off) in the device, not in the network. [b]ADRbit[/b] - ADRBit (Adaptive Data Rate on or off) set by the device. [b]AppEUI[/b] - The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame. The AppEUI is supplied by KPN. [b]AppSKey[/b] - Application Session Key. This key is unique per end-device and it is shared between the end-device and theApplication Server. It is used to encrypt/decrypt Application Server messages to the end-device. [b]AS[/b] - Application Server. Runs the application by decrypting the packets coming from the Network Server. Each Application Server has its own and unique Application Session key (AppSKey). [b]Channel[/b] - Radio Channel (LC) used by the device. [b]CustomerData[/b] - ASCII customer data set by pr
KPN debugger ontvangt geen berichten.
Hallo, Voor een project maak ik momenteel gebruik van een RN2483 LoRa daughterbord van Microchip. Tot vandaag kon ik verzonden berichten uitlezen met behulp van de KPN debugger. Momenteel verschijnen er geen nieuwe verzonden berichten meer op de KPN debugger of in hookbin. Het bord reageert wel op uart commando's. Kan iemand mij vertellen wat wellicht de oorzaak kan zijn en of er momenteel onderhoud wordt gepleegd aan het LoRa netwerk De GPS coordinaten van de dichtsbijzijnde LoRa mast zijn: 52.026318, 4.551069 (Bleiswijk) PS: Ik had ook nieuwe keys aangemaakt. De nieuwe keys hadden geen effect.
Achterhouden AppSKey voor KPN in combinatie met OTAA
Volgens het topic "Lora Decryption on Application Server" moet het mogelijk zijn om de AppSKey niet op te geven in Thingpark, zodat de applicatiedata op de applicatieserver zelf ontsleuteld moet worden en KPN dus niet over deze sleutel beschikt. Echter is bij OTAA de procedure dat aan de hand van de AppKey, de AppNonce, DevNonce en NetID aan beide kanten de NwkSkey en AppSKey worden berekend. In dat geval beschikt KPN dan toch alsnog over de AppSKey? Impliceert dit dat de mogelijkheid om de AppSKey achter te houden, enkel werkt in combinatie met ABP?
Sodaq ONE - mac_err
Beste Heren/Dames, Momenteel zijn wij aan het testen met de LoRa en gebruiken hiervoor de SODAQ ONE (http://support.sodaq.com/sodaq-one/) met de Universal Tracker 2.0 (https://github.com/SodaqMoja/SodaqOne-UniversalTracker) applicatie. [b]Echter komen de berichten verzonden van de SODAQ niet aan op het developers portal.[/b] Telkens word de melding "mac_err" getoond en volgens de RN2483 (http://ww1.microchip.com/downloads/en/DeviceDoc/40001784B.pdf) datasheet is dit omdat: "mac_err - if transmission was unsuccessful, ACK not received back from the server". Wat erop lijkt dat er geen berichten terug komen. De testen worden buiten uitgevoerd in Enschede (omgeving van Universiteit Twente) hier zouden 3 masten dekking op moeten geven. de berichten worden per 5 minuten gestuurd wat na verloop van tijd een "busy" oplevert en volgens de datasheet "if the transceiver is currently busy" betekend. Helaas is er ook nog helemaal niks aangekomen op de Gateways, en word de status "busy" n
Downlink berichten verstuurd op channel LC127
Sinds kort zijn we bezig met het implementeren van een eigen Lora-node en we testen deze node op het KPN Lora netwerk. De node laten we nu met ABP verbinden met het KPN netwerk. Op sommige momenten komen downlink MAC en databerichten netjes aan op de node, echter de laatste tijd komen de MAC en databerichten niet meer aan op de node. De software op de node is de gehele tijd hetzelfde gebleven. Wat opvalt is het volgende: voorheen (toen de berichten nog aankwamen) was op de wlogger te zien dat de berichten werden verzonden naar de node op channel RX2. Nu worden deze berichten op channel LC127 verstuurd. Het vermoeden is dan ook dat dit de oorzaak is van het probleem. Nu de vraag: waarom wordt nu opeens LC127 gebruikt? En welk channel is LC127?
The secret suffix method
While reading through some of the API documentation of the Developer Portal I stumbled upon the use of the secret suffix method to produce a MAC to authenticate the sender of a payload. It is well known that cryptographers advice against using this method.. What is the rationale for using the secret suffix method instead of an HMAC function (which is designed for this type of thing)?
KPN LoRa Developer Portal
[color=green][h3]Getting started with the free KPN LoRa developer portal[/h3][/color] The [url=http://loradeveloper.mendixcloud.com/login.html]LoRa developer portal[/url] was built to enable developers [u]free[/u] access to the KPN LoRa network. This portal allows testing with up to 10 devices for a period of 6 months. The developer portal can be used for testing with Class A Activation-By-Personalisation (ABP) and Class A Over-The-Air-Activation (OTAA) devices. Note that on the KPN live network, only OTAA devices are allowed and it is thus recommended to start developing with OTAA right away. All a developer has to provide is a forwarding address (endpoint) for the Application Server to get the device credentials (DevEUI, AppSKey and NwkSKey, in case of an ABP device). Upload these credentials to your LoRa device and you are good to go. [color=green][h3]Differences between ThingPark and the Developer Portal[/h3][/color] The aim of the KPN Lora Developer Portal is to enable user
Lora Decryption on Application Server
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/there-are-online-lora-tools-and-reference-code-available-to-make-your-life-easier-10110]There are online LoRa tools and reference code available to make your life easier[/url] topic. [spoiler][i]This topic is only for paying LoRa customers that do not give their AppSKey in Thingpark. Other cases do not need to have this decryption scheme on their application server and this is done automatically by KPN servers![/i] In this topic we describe how to decrypt an encrypted LoRa message on an applications server. The user is assumed to know how different authentication methods and keys are used, see [url=https://zakelijkforum.kpn.com/lora-forum-16/lora-forum-and-manuals-8318] index topic[/url]. This topic focuses on decrypting the payload once you have received it properly. [h3]Introduction: Customer-Side Decryption[/h3] The LoRa payload is by default encrypted with AES-128
Requirements for your LoRa Devices
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/certification-and-requirements-of-lorawan-devices-10958]Certification and requirements of LoRaWAN devices[/url] topic. [spoiler]If you are going to make your own LoRa device it is important to know what requirements KPN gives for our devices. Here are a few requirements and some advise on how to build and config your device. [list] [*] [b]Certification[/b]: Each commercial LoRa solution with more than a few devices must be certified by the LoRa Alliance. See [url=https://zakelijkforum.kpn.com/lora-forum-16/certificering-devices-8327]this topic[/url] for more information. [*] [b]OTAA [/b]: Each solution with more than 256 devices must use Over the Air Activation ([url=https://zakelijkforum.kpn.com/lora-forum-16/over-the-air-activation-otaa-8323]OTAA[/url]). This adds security becasue session keys can be renewed and enables easy roaming from one provider to another. [*] [b
Packet Loss with LoRa
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/certification-and-requirements-of-lorawan-devices-10958]Certification and requirements of LoRaWAN devices[/url] topic. [spoiler]The LoRa protocol is very lightweight to reduce battery consumption and does not contain as many error correction methods as conventional communication protocols. KPN strives to have a optimal network performance., but will not be able to avoid collisions between LoRa packets in the air interface, meaning missed packets that will not be resend by the protocol. Solution Providers should build in error correction methods in their application to compensate for missed packets. There are several error correction methods available. The most straightforward method is to include the last few measurements in a new packet. This will be a challenge on your payload size, so you might want to check out other methods.[/spoiler]
Examples of uplink messages
When creating your application server it of course important to know the type of messages your application server can expect. Through the IoT Academy I've created some examples on Github of J-SON formatted POST messages from KPN Thingpark and the Developer Portal. Also, an example script is available to simulate these messages from your laptop, so you don't need a LoRa device that sends very often to continue developing, Please refer to [url]https://github.com/iotacademy/LoRaPayloadSimulator/[/url] and do a pull request if you have any enhancements. Also, you can ask your questions about these example below. [i]Click [url=https://zakelijkforum.kpn.com/lora-forum-16/lora-forum-and-manuals-8318]here[/url] to go back to the index topic[/i]
Sending Downlink messages
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/setting-up-your-application-server-11069]Setting up your Application Server[/url] topic. [spoiler][color=green][h1]Developer Portal[/h1][/color] [b][u]Sending downlink messages[/u][/b] All downlink messages should be sent to: https://loradeveloper.mendixcloud.com/rest/sendkpnloramessage and contain the following query parameters: - [b]DevEUI [/b]of your device - [b]FPort [/b]used within LoRa (developer portal only allows port 1) - [b]Payload [/b]formatted as hex - [b]AS_ID[/b] that identifies you. You can find your AS_ID at you profile in the developer portal. - [b]Timestamp [/b]formatted as ISO time [b][u]Example[/u][/b] [i]DevEUI=000000000F1D8693&FPort=1&Payload=00&AS_ID=app1.sample.com&Time=2016-01-11T14:28:00[/i] Also a token should be added by computing it from SHA-256 [i]SHA 256(DevEUI=000000000F1D8693&FPort=1&Payload=00&AS_ID=app1.sample.com&Time=2
LoRa | Frequently Asked Questions (FAQ)
[b]Where should I start on this forum?[/b] Please see [url=https://zakelijkforum.kpn.com/lora-forum-16/welcome-to-the-kpn-lora-forum-an-overview-11123]this[/url] topic.. [b]How do I get my LoRa keys?[/b] LoRa keys refers to the identifiers required to join the (KPN) network. Depending on your account type there are different ways to get your keys: [list] [*] For developers the keyset can be obtained via the [url=https://zakelijkforum.kpn.com/lora-forum-16/kpn-lora-developer-portal-8429]KPN LoRa Developer Portal[/url]. [*] If you are connected to the KPN network via a reseller (e.g. SIMPoint), then contact the reseller. [*] For customers that are directly connected via KPN please contact your account manager. [/list] [b]What are the requirements for the AppSKey, NwkSkey & AppKey?[/b] The keys should be 128 bits (RFC 4493, SAE 128-cmac). Implying 32 random hexadecimal characters. One can refer to the topic on [url=https://zakelijkforum.kpn.com/lora-forum-16/there-are-online
Certificering van Devices
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/certification-and-requirements-of-lorawan-devices-10958]Certification and requirements of LoRaWAN devices[/url] topic. [spoiler]To insure that KPN can offer a good and stable network, every LoRa device must be certified to be allowed on the network. The certification can be executed by several official [i]test service providers[/i] of the LoRa Alliance. More about the certification can be found at [url=https://www.lora-alliance.org/Products/Certification-Overview]site of the LoRa Alliance[/url]. In order to enable development KPN allows small volumes of uncertified devices (less than 256). This is only allowed in development projects that have a goal of certification in the long term. In short: [list] [*]To connect new types of devices on the KPN LoRa Network, a proof of certification is needed. [*]When devices or modules are used that are certified themselves, no extr
Over The Air Activation (OTAA)
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/over-the-air-activation-otaa-of-devices-11076]Over the air activation (OTAA) of devices[/url] topic. [spoiler]With Over The Air Activation (OTAA) a device joins a specific LoRa network using the DevEUI and an AppEUI together with an AppKey. The [b]DevEUI[/b] is an End Device Unique Identifier DevEUI (64 bits) and must be unique for all LoRaWAN networks. The DevEUIs are administrated by the IEEE. The [b]AppEUI[/b] is a global application ID in IEEE EUI64 address space that uniquely identifies the application provider (i.e., owner) of the end-device. The [b]AppKey[/b] is an AES key, used only when joining the network with OTAA. [b]The Join Procedure[/b]: [list][*]The device sends an unencrypted LoRa join request with the AppEUI, DevEUI, and a random generated and unique DevNonce. [*]If the network allows the device, then a join accept is sent to the device containing a r
Activation by Personalisation
There are 2 methods of device activation, namely [url=https://zakelijkforum.kpn.com/lora-forum-16/over-the-air-activation-otaa-of-devices-11076]Over The Air Activation (OTAA)[/url] and Activation By Personalisation (ABP). [b]ABP is not allowed on the KPN live network. [/b]On the [url=https://zakelijkforum.kpn.com/lora-forum-16/kpn-lora-developer-portal-8429]developer portal[/url] it is still allowed, however KPN encourages users to use OTAA also in the development phase, since this makes it easier to scale up in the long run. [spoiler]Every device has a unique identifier within a specific LoRa network, a Device Address: DevAddr (32 bits). Both Core and Device must know this [b]DevAddr[/b] plus the [b]NwkSKey[/b] and optionally the [b]AppSKey[/b]. Globally, an End Device Unique Identifier DevEUI (64 bits) is defined, that is unique for all LoRaWAN networks. The DevEUIs are administrated by the IEEE. Messages can be sent when DevAddr, NwkSKey and AppSKey are set. For small numbers of
Encryption of LoRa messages
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/lorawan-security-encryption-and-authentication-10957]LoRaWAN Security: Encryption and Authentication[/url] topic. [spoiler]LoRaWAN forces all devices to encrypt payload and header with the Advanced Encryption Standard (AES), using keys of 128 bits (or 32 hexadecimal characters): [list][*]Network information is encrypted with a Network Session Key ([b]NwkSKey[/b]). This key needs to be shared between device and KPN LoRa Core. [*]Payload information is encrypted with a Application Session Key ([b]AppSKey[/b]). This key needs to be shared between device and customer Application Server. The AppSKey does not have to be shared with the network operator, but developers can choose to share the AppSKey with KPN to decrypt the payload and sent the decrypted payload over a secure https connection.[/list] AppSKey and NwkSKey can be generated as a string of 32 random hex characters.
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/welcome-to-the-kpn-lora-forum-an-overview-11123]Welcome to the KPN LoRa forum. An overview[/url] topic. [spoiler]LoRa devices communicate by broadcasting the LoRa signal to every LoRa receiver in the vicinity. The core server collects the messages from all gateways and ignores identical messages and remembers the gateway that had the best reception, e.g. the Last Best Gateway (LBG). For downlink messages, the LBG is selected to act as sender. For class A devices, LBG is always up to date because the network queues the downlink message to respond shortly after receiving an uplink message. For class C devices, LBG can be outdated if device is moved or environment has changed. A solution could be to send an uplink when a device stopped moving and/or sending an acknowledgment from the device when receiving a message.[/spoiler]
LoRa Device Classes
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/lorawan-device-classes-a-b-and-c-10972]LoRaWAN Device Classes: A, B and C[/url] topic. [spoiler]LoRa devices operate in three different classes: A,B or C. Both network and device must now what device class is used in order to set up proper communication. [b]Class A (Default): Bi-directional devices[/b] Completely uplink oriented. Uplink transmission is followed by two receive slots. Downlink transmissions are queued in network until next uplink creates two receive slots. Radio sleeps the rest of the time and battery is preserved. Note that the network cannot send a downlink until the device wakes up (triggered by an event on the device like a timer or a sensor threshold) [img]90a1a854-7cb4-42f5-8bee-f1db2fa16680.png[/img] [b]Class C (Continuous): Bi-directional devices with maximal receive slots[/b] Device never sleeps, but always listens between uplinks. The device is
LoRa | Forum Index & Manuals
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/welcome-to-the-kpn-lora-forum-an-overview-11123]Welcome to the KPN LoRa forum. An overview[/url] topic. [spoiler]Welkom to the KPN LoRa forum. Here you can find information about different LoRa topics. Please refer to one of the topics below and ask your questions if anything remains unclear. [video]https://www.youtube.com/watch?v=v1Jroykcy3E[/video] [b]KPN LoRa Basics[/b] [url=https://zakelijkforum.kpn.com/lora-nieuws-updates-18/what-lora-and-lorawan-8314]What is LoRa and LoRaWAN?[/url] [url=https://zakelijkforum.kpn.com/lora-nieuws-updates-18/spreading-factors-and-coverage-8315]Spreading factors and Coverage[/url] [url=https://zakelijkforum.kpn.com/lora-nieuws-updates-18/adaptive-data-rate-adr-8316]Adaptive Data Rate[/url] [url=https://zakelijkforum.kpn.com/lora-nieuws-updates-18/ism-868-band-and-the-duty-cycle-8317]ISM 868 band and the duty cycle[/url] [url=https:
ISM 868 band and the duty cycle
This post has become obsolete as it was incorporated in the [url=https://zakelijkforum.kpn.com/lora-forum-16/uplink-and-downlink-messages-and-the-duty-cycle-10909]Uplink and Downlink messages and the Duty Cycle[/url] topic. [spoiler][h3] ISM868 regulations [/h3] In Europe LoRa uses unlicensed frequency spectrum in 868 MHz band (ISM). Devided in sub-bands between 863 and 870 Mhz. Everyone is allowed to use this spectrum, but has to obey restrictions determined and enforced by the government per ISM (sub)-band. Generally speaking: [list][*]Devices are not allowed to exceed a maximum power output of 14 dBm (25 mW) [*]Devices are only allowed a limited time-on-air (time it is sending). This duty-cycle is maximum 1% of an hour for that sub-band. [/list] LoRa devices are allowed to use different ISM Bands independently, therefore increasing the time on air allowed. Which channels in which band are used are set by KPN. [u][b]LoRaWAN specifies that each time a message is send in one
Meld je aan
Heb je al een account? Inloggen
Inloggen of registreren met sociaal netwerkInloggen met Facebook Login with LinkedIn
Nog geen account? Maak een account aan
Inloggen of registreren met sociaal netwerkInloggen met Facebook Login with LinkedIn
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.