0
1
00:00:00,390 --> 00:00:05,310
We still have our two entities that have split up at the top and at the bottom of the screen.
1

2
00:00:05,790 --> 00:00:07,940
At the top there is the LoRaWAN server.
2

3
00:00:07,950 --> 00:00:12,030
And at the bottom there is the IoT platform with the user application.
3

4
00:00:12,780 --> 00:00:15,150
Let's look at the uplink stream first.
4

5
00:00:15,690 --> 00:00:22,620
In fact, if you think about it, the ideal solution isn't that the IoT platform requests the opening messages,
5

6
00:00:22,620 --> 00:00:28,410
but instead it would be much better if the LoRaWAN server could push these messages without being
6

7
00:00:28,410 --> 00:00:29,100
requested.
7

8
00:00:29,820 --> 00:00:36,030
This is possible with the HTTP protocol, but the request will be different from the one we saw before.
8

9
00:00:36,060 --> 00:00:42,990
This time the request is called an HTTP POST request and not HTTP GET.
9

10
00:00:43,590 --> 00:00:49,860
In that case, the LoRaWAN server is the client and the IoT platform is the server to which we'll
10

11
00:00:49,860 --> 00:00:52,290
connect to send the uplink messages.
11

12
00:00:52,830 --> 00:00:57,960
With this way of proceeding, each time a data arrives, it's transmitted.
12

13
00:00:58,350 --> 00:01:02,250
We can say that each time a data arrives it's POSTED.
13

14
00:01:02,430 --> 00:01:07,210
Hence the name HTTP POST request. With an HTTP POST,
14

15
00:01:07,230 --> 00:01:12,780
there is a very low latency between the time it arrives on the client and the time it arrives on the
15

16
00:01:12,780 --> 00:01:13,920
IoT platform.
16

17
00:01:13,920 --> 00:01:16,650
It's almost sent instantaneously.
17

18
00:01:17,610 --> 00:01:21,750
For the downlink now, we'll have exactly the same approach.
18

19
00:01:21,960 --> 00:01:29,460
The user downlink is stored on the IoT platform and in the same way the IoT platform will post the downlink
19

20
00:01:29,460 --> 00:01:32,130
message using an HTTP POST request.
20

21
00:01:32,520 --> 00:01:39,270
In that situation, the IoT platform is the client and the LoRaWAN server is the HTTP server.
21

22
00:01:39,450 --> 00:01:45,300
With this way of doing it, each time a downlink message is generated by the user, it's transmitted
22

23
00:01:45,300 --> 00:01:46,590
to the LoRaWAN server.
23

24
00:01:46,920 --> 00:01:52,530
We can also say that it's POSTED, and therefore, there is a very low latency between the time the downlink
24

25
00:01:52,530 --> 00:01:57,660
message is generated on the IoT platform and the time it arrives on the LoRaWAN server.
25

26
00:01:59,310 --> 00:02:05,000
So let's make a demonstration of this and this time we'll do it in both directions:
26

27
00:02:05,010 --> 00:02:07,530
So uplink and downlink messages.