forked from TheThingsIndustries/lorawan-stack-docs
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathglossary.yml
More file actions
362 lines (282 loc) · 25.3 KB
/
glossary.yml
File metadata and controls
362 lines (282 loc) · 25.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
# Glossary of terms
# Formatted as:
# <Term>:
# description: <Description>
# link: <Link> or <Ref> e.g https://wikipedia.com or /reference/api
# abbr:
# - <Abbr 1>
# - <Abbr 2>
# alt:
# - <Alt term 1>
# - <Alt term 2>
- term: Tenant ID
description: A Tenant ID is given to you by The Things Industries when you register for a Cloud account. Your Tenant ID is part of the URL of your deployment, i.e https://<tenant-id>.eu1.thethings.industries.
- term: Join Server
description: A Join Server is a component of the LoRaWAN server defined in the LoRaWAN Backend Interfaces. The Things Stack contains a Join Server, which is used by default unless an External Join Server is specified. The Join Server's role is to store root keys, generate session keys, and to send those securely to the Network Server and Application Server of choice. The device contains the same root keys, which can be provisioned as part of assembly, distribution or upon installation. An External Join Server allows for secure end device provisioning without network lock-in. The owner uses a device claiming procedure to transfer ownership in the Join Server.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm-backend-interfaces-v1.0.pdf#page=9
- term: Network Session Encryption Key
abbr:
- NwkSEncKey
description: A network session key used to encrypt and decrypt MAC commands transmitted on FPort 0, which contain no application payload. When a LoRaWAN 1.1 capable device connects to a LoRaWAN 1.0x Network Server, the value of FNwkSIntKey is used as the value of SNwkSIntKey and NwkSEncKey.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm_specification_-v1.1.pdf#page=50
- term: Serving Network Session Integrity Key
abbr:
- SNwkSIntKey
description: A network session key used to calculate all of the message integrity code for downlink messages and half of the message integrity code for uplink messages. When a LoRaWAN 1.1 capable device connects to a LoRaWAN 1.0x Network Server, the value of FNwkSIntKey is used as the value of SNwkSIntKey and NwkSEncKey.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm_specification_-v1.1.pdf#page=50
- term: Forwarding Network Session Integrity Key
abbr:
- FNwkSIntKey
description: A network session key used to calculate all or half of the message integrity code for uplink messages. When a LoRaWAN 1.1 capable device connects to a LoRaWAN 1.0x Network Server, the value of FNwkSIntKey is used as the value of SNwkSIntKey and NwkSEncKey.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm_specification_-v1.1.pdf#page=50
- term: Network Key
abbr:
- NwkKey
description: A device specific encryption key used to derive the FNwkSIntKey, SNwkSIntKey, NwkSEncKey in LoRaWAN 1.1. When a LoRaWAN 1.1 capable device connects to a LoRaWAN 1.0x Network Server which does not support dual root keys (NwkKey and AppKey), the NwkKey value is used as the AppKey value.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawantm_specification_-v1.1.pdf#page=48
- term: Data Rate Offset
description: The Data Rate Offset sets the offset between the uplink data rate and the downlink data rate used to communicate with the End Device during the first reception slot (RX1).
link: https://lora-alliance.org/wp-content/uploads/2020/11/rp_2-1.0.1.pdf#page=27
- term: Data Rate Index
description: The Data Rate Index specifies which data rate downlink communications will use, as given in the Regional Parameters.
link: https://lora-alliance.org/wp-content/uploads/2020/11/rp_2-1.0.1.pdf#page=25
- term: Packet Forwarder
description: A Packet Forwarder is a program running on a Gateway that receives and transmits LoRa packets, and forwards these packets to and from a Network Server.
- term: Semtech UDP Packet Forwarder
description: The Semtech UDP Packet Forwarder is the first packet forwarder, connecting to servers through the Semtech UDP protocol. Although this protocol has several drawbacks, many gateways include a pre-compiled version of the packet forwarder, which makes it easy to test a gateway with this protocol.
alt:
- UDP Packet Forwarder
- term: LoRa Basics™ Station
description: "The LoRa Basics™ Station protocol simplifies management of large scale LoRaWAN networks. LoRa Basics™ Station is the preferred way of connecting Gateways to The Things Stack. Some of the advantages of LoRa Basics™ Station over the legacy UDP Packet Forwarder are: Centralized Update and Configuration Management, TLS and Token-based Authentication, Centralized Channel-Plan Management, and No Dependency on Local Time Keeping."
abbr:
- LBS
alt:
- Basic Station
- Station
link: https://lora-developers.semtech.com/resources/tools/basic-station/welcome-basic-station/
- term: Activation Mode
description: "**Over-the-Air Activation (OTAA)** is the preferred and most secure way to connect a device. Devices perform a join-procedure with the network, during which a dynamic Device Address is assigned and security keys are negotiated with the device. **Activation by Personalization (ABP)** requires hardcoding the Device Address as well as the security keys in the device. This strategy might seem simpler, because you skip the join procedure, but it has downsides related to security. ABP also has the downside that devices can not switch network providers without manually changing keys in the device. **Multicast** is a virtual group of ABP devices which allows all devices to receive the same downlinks. Multicast groups do not support uplinks."
- term: Gateway
description: Gateways form the bridge between [End Devices](#end-device) and Network Servers. Devices use low power networks like LoRa to connect to the Gateway, while the Gateway uses high bandwidth networks like WiFi, Ethernet or Cellular to connect to a Network Server.
link: https://www.thethingsnetwork.org/docs/gateways/
- term: Gateway ID
description: A unique, human-readable identifier for your gateway.
- term: Gateway EUI
description: A 64 bit extended unique identifier for your gateway. This is programmed by the manufacturer and should not be changed. In cases where it is not programmed by the manufacturer, it must be programmed with a unique EUI that you own.
link: https://www.thethingsnetwork.org/docs/lorawan/addressing.html
- term: Network Server
description: The Network Server is responsible for routing Internet of Things data between devices and applications.
link: https://www.thethingsnetwork.org/docs/network/
alt:
- Backend
- term: Application
description: An Application in The Things Stack allows you to register LoRaWAN devices and manage data and integrations. Applications can be created via the Console or CLI.
link: https://www.thethingsnetwork.org/docs/applications/
- term: Integration
description: Integrations connect devices to the world, by triggering events whenever a device communicates. The Application server manages integrations using Webhooks or MQTT. These can be as simple as an IFTTT Maker Applet or a visual flow using Node-RED, or as complex as custom code on a server which processes and acts on device data.
link: https://www.thethingsnetwork.org/docs/applications/integrations.html
- term: LoRaWAN
description: LoRaWAN is a media access control (MAC) protocol for wide area networks. It is designed to allow low-powered devices to communicate with Internet-connected applications over long range wireless connections.
link: https://lora-alliance.org/about-lorawan
- term: LoRa
description: A modulation technology for long range wireless communication, based on chirp-spread spectrum technology.
link: https://en.wikipedia.org/wiki/LoRa
- term: End Device
description: A sensor or actuator with an embedded low power LoRaWAN communication module.
link: https://www.thethingsnetwork.org/docs/devices/
alt:
- Device
- Node
- Mote
- term: LoRaWAN Version
description: The LoRaWAN version is the LoRa Alliance LoRaWAN specification your device conforms to, which defines which Media Access Control features it supports. The LoRaWAN version for your device should be provided by the manufacturer in a datasheet as LoRaWAN version or LoRaWAN specification. The most commonly used LoRaWAN versions are v1.0.2 and v1.0.3. ({{% ttnv2 %}} uses v1.0.2 by default).
- term: Media Access Control
description: LoRaWAN media access control protocols, downloadable from the LoRa Alliance. The Media Access Control version for your device should be provided by the manufacturer in a datasheet as LoRaWAN version or LoRaWAN specification.
link: https://lora-alliance.org/lorawan-for-developers
abbr:
- MAC
- term: Regional Parameters
description: The Regional Parameters specify frequency, dwell time, and other communication settings for different geographical areas. The Regional Parameters version is the version of the LoRa Alliance specification which your device supports. This should be provided by the device manufacturer in a datasheet.
link: https://lora-alliance.org/wp-content/uploads/2019/11/rp_2-1.0.0_final_release.pdf
abbr:
- PHY
- term: Physical Layer
description: Hardware pertaining to LoRaWAN official regional specifications. The PHY version for your device should be specified in the product documentation as Regional Parameter version.
link: https://lora-alliance.org/wp-content/uploads/2019/11/rp_2-1.0.0_final_release.pdf
abbr:
- PHY
- term: Local area network
description: A network that connects computers within a limited area.
link: https://en.wikipedia.org/wiki/Local_area_network
abbr:
- LAN
- term: Wide area network
description: A network that connects within a wide geographical range, usually to the internet.
link: https://en.wikipedia.org/wiki/Wide_area_network
abbr:
- WAN
- term: ISM Radio Bands
description: The Industrial, Scientific, and Medical Bands, most commonly used for low-power and short range telecommunications, such as WiFi, Bluetooth, Zigbee, wireless telephones, RFID, and NFC.
link: https://en.wikipedia.org/wiki/ISM_band
- term: Payload
description: A LoRaWAN packet. Application payloads are decrypted data relevant to the application. Gateway payloads are encrypted and include the application payload plus a frame counter and other LoRaWAN data.
- term: Interval
description: The duration between messages.
link: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
- term: Duty Cycle
description: The fraction of time a device is busy. When a single device transmits on a channel for 2 time units every 10 time units, this device has a duty cycle of 20%.
link: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
- term: Data Rate
description: A combination of Bandwidth and Spreading Factor which defines how quickly a message is transmitted.
link: https://www.thethingsnetwork.org/docs/lorawan/modulation-data-rate.html
abbr:
- DR
- term: Bandwidth
description: LoRaWAN can use channels with a bandwidth of either 125 kHz, 250 kHz or 500 kHz, depending on the region or the Frequency Plan. Making the bandwidth 2x wider (from BW125 to BW250) allows you to send 2x more bytes in the same time.
link: https://www.thethingsnetwork.org/docs/lorawan/modulation-data-rate.html
- term: Spreading Factor
description: The transmission speed or Data Rate of a LoRaWAN message, ranging from SF7 (highest Data Rate) to SF12 (lowest Data Rate). Making the spreading factor 1 step lower (from SF10 to SF9) allows you to roughly send the same amount of data use half the time on air. Lowering the spreading factor makes it more difficult for the gateway to receive a transmission, as it will be more sensitive to noise.
link: https://www.thethingsnetwork.org/docs/lorawan/modulation-data-rate.html
abbr:
- SF
- term: Adaptive Data Rate
description: A mechanism for optimizing data rates, airtime and energy consumption in the network.
link: https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate.html
abbr:
- ADR
- term: Signal to noise ratio
description: A measure of signal strength.
link: https://en.wikipedia.org/wiki/Signal-to-noise_ratio
abbr:
- SNR
- term: Classes
description: The LoRaWAN specification defines three device types. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices.
link: https://www.thethingsnetwork.org/docs/lorawan/classes.html
- term: Class A
description: Class A devices support bi-directional communication between a device and a gateway. Uplink messages (from the device to the server) can be sent at any time (randomly). The device then opens two receive windows at specified times after an uplink transmission. The first receive window (Rx1) is set to 5 seconds and can be modified. The second receive window (Rx2) always comes 1 second after Rx1.
link: https://www.thethingsnetwork.org/docs/lorawan/classes.html
- term: Class B
description: Class B devices extend Class A by adding scheduled receive windows for downlink messages from the server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows.
link: https://www.thethingsnetwork.org/docs/lorawan/classes.html
- term: Class C
description: Class C devices extend Class A by keeping the receive windows open unless they are transmitting. This allows for low-latency communication but is many times more energy consuming than Class A devices.
link: https://www.thethingsnetwork.org/docs/lorawan/classes.html
- term: Device ID
description: A unique, human-readable identifier for your device. You make it up, so be creative. Device IDs can not be used by multiple devices within the same application.
- term: Device EUI
description: A 64 bit extended unique identifier for your device. This is programmed by the manufacturer and should not be changed. It should be provided to you by the manufacturer, or printed on the device.
link: https://www.thethingsnetwork.org/docs/lorawan/addressing.html
abbr:
- DevEUI
- term: Device Address
description: A 32 bit non-unique identifier, assigned by the Network Server during device activation.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=33
abbr:
- DevAddr
- term: Application ID
description: A unique, human-readable identifier for your application.
abbr:
- AppID
- term: JoinEUI
description: The JoinEUI (formerly called AppEUI) is a 64 bit extended unique identifier used to identify the Join Server during activation. This should be provided by the device manufacturer for pre-provisioned devices, or by the owner of the Join Server you will use. If you do not have a JoinEUI, it is okay to use `0000000000000000`, but ensure that you use the same JoinEUI in your device as you enter in The Things Stack.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=33
- term: AppEUI
description: In LoRaWAN specifications prior to 1.1, JoinEUI was called AppEUI. See JoinEUI.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=33
alt:
- JoinEUI
- term: Application Session Key
description: After activation, this encryption key is used to secure messages which carry a payload.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=33
abbr:
- AppSKey
- term: Network Session Key
description: After activation, this encryption key is used to secure messages which do not carry a payload.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=33
abbr:
- NwkSKey
- term: Application Key
description: A device specific encryption key used during OTAA to derive the AppSKey (in LoRaWAN 1.1x) or both the NwkSKey and AppSKey in LoRaWAN 1.0x. This is usually pre provisioned by the device manufacturer, but can also be created by the user.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=34
abbr:
- AppKey
- term: Over the Air Activation
description: The preferred method to join a LoRaWAN network, offering more flexibility, security, and scalability than ABP.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=34
abbr:
- OTAA
- term: Activation by Personalisation
description: Manually provisioning device keys to join a LoRaWAN network. Less flexible, less secure, and less scalable than OTAA, but sometimes useful during demos, to avoid waiting for a downlink window to join a network.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=37
abbr:
- ABP
- term: Dwell Time
description: The time needed to transmit a LoRaWAN message. In some regions a maximum allowed dwell time is configured to limit transmission time, typically 400ms.
- term: Dwell Time Configuration
description: The Dwell time restrictions are configurable for each Frequency Plan. In regions where dwell time limitations are optional, they're disabled by default.
- term: Band
description: For LoRaWAN, a Band is a range of frequencies divided either in to dynamic channels (i.e. EU868) or fixed channels (i.e. US902, AU915). The LoRaWAN Regional Parameters specify which Bands are supported by LoRaWAN in a geographical area. Within a Band, there can be multiple complying Frequency Plans. Devices typically support one or more Bands in their hardware, and are configured for a particular Frequency Plan as part of activation.
link: https://lora-alliance.org/wp-content/uploads/2019/11/rp_2-1.0.0_final_release.pdf
alt:
- Frequency Band
- term: Frequency Plan
description: A Frequency Plan defines data rates and channels which comply with the LoRaWAN Regional Parameters for a band or geographical area. Devices are configured for a particular Frequency Plan as part of activation, and can use any Frequency Plan within a supported band.
link: https://github.com/TheThingsNetwork/lorawan-frequency-plans
abbr:
- FP
alt:
- Channel Plan
- term: Dynamic Channel
description: A Band which uses Dynamic Channels (i.e. EU868) uses a Channel Frequency List (CFList) to communicate channels by frequency.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=50
- term: Fixed Channel
description: A Band which uses Fixed Channels (i.e. US902, AU915) uses a Channel Mask (ChMask) to enable and disable channels.
link: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf#page=50
- term: Class B timeout
description: Time after sending a class B confirmed downlink message in a ping slot to wait for an uplink message with acknowledgment that the confirmed downlink message was received. The Network Server waits for the uplink message with acknowledgment to arrive or for this class B timeout to expire before scheduling other downlink messages. The Things Stack does not schedule MAC commands in class B downlink; the only type of downlink messages that require an uplink message within this timeout are confirmed application data downlink messages.
- term: Class C timeout
description: Time after sending a class C confirmed downlink message to wait for an uplink message with acknowledgment that the confirmed downlink message was received. The Network Server waits for the uplink message with acknowledgment to arrive or for this class C timeout to expire before scheduling other downlink messages. The Things Stack does not schedule MAC commands in class C downlink; the only type of downlink messages that require an uplink message within this timeout are confirmed application data downlink messages.
- term: ADR enabled
description: Whether or not Adaptive Data Rate (ADR) is enabled for the end device to optimize the data rate and power consumption based on signal strength and noise ratio. Enable this for stationary end devices and for end devices that set the LoRaWAN ADR bit in uplink messages. If this setting is enabled, but the end device does not ask for ADR in uplink messages, ADR will not be applied. Disable ADR for moving devices like asset trackers.
- term: Resets FCnt
description: Enable this to allow end devices to reset their frame counter (FCnt). This is not LoRaWAN compliant and this is not secure. This is to support ABP end devices that reset their frame counter on a power cycle. Do not use this setting in production.
- term: Status time periodicity
description: Interval to request the device status by transmitting the `DevStatusReq` MAC command. Set to 0 to disable requesting the device status on an interval.
- term: Status count periodicity
description: Number of uplink messages after which the device status is requested by transmitting the `DevStatusReq` MAC command. Set to 0 to disable requesting the device status based on the number of uplink messages.
- term: RX1 delay
description: Time in seconds after an uplink transmission until the first receive window (RX1) opens. The second receive window (RX2) opens exactly 1 second after RX1. OTAA devices receive the RX1 delay as part of the join-accept. Changing the desired value during an OTAA or ABP session makes the Network Server transmit the `RXTimingSetupReq` MAC command.
- term: RX1 data rate offset
description: Used to lower data rate in the first receive window (RX1). When using 0, there is no offset applied. A value higher than 0 reduces the RX1 data rate. See LoRaWAN Regional Parameters to lookup the downstream data rate in RX1 for each offset value. OTAA devices receive the RX1 data rate offset as part of the join-accept. Changing the desired value during an OTAA or ABP session makes the Network Server transmit the `RXParamSetupReq` MAC command.
- term: RX2 data rate index
description: The second receive window (RX2) uses a fixed frequency and data rate. This value configures the data rate to use in RX2. See LoRaWAN Regional Parameters to find the band's modulation settings for each data rate index. OTAA devices receive the RX1 data rate offset as part of the join-accept. Changing the desired value during an OTAA or ABP session makes the Network Server transmit the `RXParamSetupReq` MAC command.
- term: RX2 data rate frequency
description: The second receive window (RX2) uses a fixed frequency and data rate. This value configures the frequency to use in RX2. Changing the desired value makes the Network Server transmit the `RXParamSetupReq` MAC command.
- term: Maximum duty cycle
description: The maximum aggregated transmit duty cycle of the end device over all sub-bands. The allowed time-on-air is 1/N where N is the given value, 1 is 100%, 1024 is 0.97%, etc. This value is used for traffic shaping. All end devices must respect regional regulations regardless of this value. Changing the desired value makes the Network Server transmit the `DutyCycleReq` MAC command.
- term: ADR ACK limit
description: This value changes the `ADR_ACK_LIMIT` value defining the ADR back-off algorithm. Changing the desired value makes the Network Server transmit the `ADRParamSetupReq` MAC command (from LoRaWAN 1.1).
- term: ADR ACK delay
description: This value changes the `ADR_ACK_DELAY` value defining the ADR back-off algorithm. Changing the desired value makes the Network Server transmit the `ADRParamSetupReq` MAC command (from LoRaWAN 1.1).
- term: Ping slot data rate index
description: The class B ping slot uses a fixed frequency and data rate. This value configures the data rate to use in class B ping slots. See LoRaWAN Regional Parameters to find the band's modulation settings for each data rate index. Changing the desired value makes the Network Server transmit the `PingSlotChannelReq` MAC command.
- term: Ping slot frequency
description: The class B ping slot uses a fixed frequency and data rate. This value configures the frequency to use in class B ping slots. Changing the desired value makes the Network Server transmit the `PingSlotChannelReq` MAC command.
- term: Beacon frequency
description: The class B beacon is sent on a fixed frequency. This value changes the frequency to use in class B beacons. Use the same setting for all end devices using class B in the network. Changing the desired value makes the Network Server transmit the `BeaconFreqReq` MAC command.
- term: Maximum EIRP
description: The maximum allowed Effective Isotropic Radiated Power (EIRP). The end device uses this value as the maximum, it shall never use a higher EIRP, but a lower EIRP is allowed. This value is given in dBm. Changing the desired value makes the Network Server transmit the `TxParamSetupReq`.
- term: Received Signal Strength Indicator
description: The received signal power in milliwatts, measured in dBm. This value is used as a measurement of how well the signal is received. RSSI is used in the ADR feedback loop to determine if a signal is being received with enough power to allow the device to increase its data rate and conserve battery. A high RSSI means the device can reduce transmission power and messages will still be received.
abbr:
- RSSI
- term: Effective Isotropic Radiated Power
description: The total power radiated from a hypothetical isotropic antenna in a single direction in watts, measured in dBm. The maximum allowed EIRP differs between regions. Antenna power provides a tradeoff between range and battery life, and is one of the components of the ADR mechanism.
abbr:
- EIRP
- term: Effective Radiated Power
description: The total power radiated by a real antenna relative to a half-wave dipole antenna.
abbr:
- ERP
- term: Hop Time
description: The amount of time needed to change from one frequency to another, in which the radio is not transmitting.