Chapitre 1

IoT : cas des réseaux de capteurs,

standard et protocole
Faouzi BOUCHHIMA
ENET’COM

1
 Un réseau de capteurs
• Un ensemble de capteurs autonomes à faible
coût, interconnectés par un réseaux de
communications
• Sert à rendre un service de mesure autour ou
dans une zone géographique
• Les nœuds du réseaux coopèrent ensembles
pour acquérir et transmettre les mesures ou
les commandes …

2
 Types de réseaux de capteurs
• En réseau, les capteurs peuvent communiquer
entre eux par le biais d’une communication
sans fils ou filaire
• Filaire : différents protocoles
• RS485 (ModBus), I2C, Mbus, etc.
• Sans fils : En effet, les réseaux de capteurs sans-
fils concentrent les dernières avancées
technologiques et représentent l’opportunité
pour de nouvelles applications
• En Anglais, on parle de « WSN » pour « Wireless
Sensor Networks ».

3
 Réseaux Ad-hoc
• Les réseaux ad-hoc sont des réseaux sans fil
capables de s’organiser sans infrastructure
définie préalablement.

Echange en mode Ad-hoc

4
 Réseau Ad-hoc
• Chaque nœud (ou node) communique directement
avec son voisin. Pour communiquer avec d’autres
nœuds , il lui est nécessaire de faire passer ses données
par d’autres qui se chargeront de les acheminer (multi
hope). Pour cela, il est d’abord primordial que les
nœuds se situent les uns par rapport aux autres, et
soient capables de construire des routes entre eux :
c’est le rôle du protocole de routage.
• Ainsi, le fonctionnement d’un réseau ad-hoc le
différencie considérablement d’un réseau comme le
réseau GSM ou des réseaux Wi-Fi avec des points
d’accès : là où une ou plusieurs stations de base sont
nécessaires à la plupart des communications entre les
différents nœuds du réseau (mode Infrastructure)
5
 Réseau de capteurs sans fils
• Réseau ad-hoc multi-hope et auto-organisé
• Possède des ressources limitées en mémoire,
puissance de calcul, bande passante et énergie
(batterie)
• Faible consommation  longue vie de batterie
• possibilité d’exploiter les sources d’énergie
renouvelable disponibles
• Taille petit (adapté) qui pourrait être intégré dans
tout environnement physique
6
Exemple représentatif d’un réseau de
capteurs sans fils

7
 Architecture typique d’un nœud de
capteurs sans fils
• Un processeur à bas cout
et faible consommation :
• Mémoire
• Calcul
• Capteurs
• Élément de
communication radio
• Lien de communication
filaire (USB, UART, etc.)
• Mémoire externe (flash)
• Une alimentation
électrique autonome

8
 Microcontrôleurs
• Microchip : famille XLP
• 1.8 – 3V
• Courant actif moins de 30μA/MHz
• Ex. PIC12F1840, PIC16F1503

• Texas Instruments MSP 430 : Il est l'un des processeurs consommant

le moins d'énergie sur le marché à l'heure actuelle
• 16 bits, RISC, 4 Mhz, on-chip RAM et ADC

• Atmel : famille AVR

• Ex. Le 8 bits ATMega128L : largement utilisé dans les nœuds de capteurs

• NXP : ultra low power, high performance wireless microcontroller

(SOC), 32-bit RISC CPU, 32MHz
• Ex. JN5148, JN5168, etc.
• 3,3V
• 17 mA à l’émission
9
 Elément de communication
• Radio transceiver (transmitter + receiver) : multiple
canals, wakeup radio, Received Signal Strength
Indicator (RSSI) . Some examples are :
• TR1000 de RFMonolithics
• 868 - 916 MHz
• CC1000 de Chipcon
• 300 - 1000 Mhz
• CC2420 de Chipcon
• Physical layer for 802.15.4
• 2,4 Ghz
• TDA 525x de Infineon
• 868 - 870 Mhz
• CC2530 de TI (SoC)
• Physical layer for 802.15.4
• 2,4 Ghz
10
 Les capteurs
• Les capteurs mesurent une variété de
grandeurs :
• Température
• Humidité
• Luminosité
• Pression
• Niveau sonore
• Vitesse, accélération, direction
• Vibration
• etc.
11
Piles et batteries électriques

12
STANDARD ET PROTOCOLE

13
14
 Topologies 802.15.4
• Deux topologies : étoile (star) ou point à point (peer to
peer)
• Etoile : les nœuds sont connectées à un nœud central
appelé coordinateur
• tous les messages sont relayés par le coordinateur
• Point à point : nœud peut communiquer directement
avec tout autre nœud à la condition qu’ils soient à
portée radio l’un de l’autre
• un coordinateur unique comme dans la topologie étoile.
Son rôle est de tenir à jour une liste des participants au
réseau et de distribuer des adresses courtes

15
 Bandes de fréquences radio

Bandes de Licence Région Débit Canaux

fréquences
868,3 MHz Sans : ISM Europe 20 Kbits/s 0
902 – 928 MHz Sans : ISM Amérique du nord 40 Kbits/s 1 - 10
2405 – 2480 MHz Sans : ISM Monde 250 Kbits/s 11 - 26

16
Bandes de fréquences radio

17
 Le protocole JenNet ?
• Destiné aux circuits (SOC) JN51xx du constructeur NXP
• Le protocole JenNet a été développé pour fournir un réseau
sans fils de faible consommation pour une large gamme
d’applications de supervision et de contrôle
• Il offre une alternative simple à la complexité du protocole
ZigBee PRO ou Zigbee 3.0
• simplifie et organise le développement de l’application, réduisant
ainsi les coûts de développement et les délais de mise sur le marché
• Basé sur le standard IEEE 802.15.4 et l’améliore par
• Installation facile et intelligente du réseau
• Routage intelligent
• Auto-correction
18
 Le protocole JenNet ?
• Peut co-exister avec d’autres technologies
comme wifi et bluetouth
• Permet au réseau d’être facilement
adapté à l'évolution des besoins en ajoutant,
supprimant ou déplaçant les nœuds du réseau
• Les nœuds peuvent disparaître ou apparaître dans le
réseau
• Le nœud peut être mis en mode économie d'énergie
(disparaître) lorsqu'il n'est pas actif

19
 Ne pas confondre

• JenNet est un protocole

– Gestion des couches hautes : réseau et applicatives
• IEEE 802.15.4 et un standard
– couches physique et MAC
• Protocole JenNet se repose sur le standard IEEE
802.15.4
– Il faut clairement séparer le standard de
l'implémentation JenNet. Il existe d'autre
implémentation, par exemple Zigbee et MIWI

20
 Ideal applications of JenNet
JenNet is suitable for a wide range of applications, covering both
commercial and domestic use, which include:
• Point-to-point cable replacement (e.g. wireless mouse, remote
controls, toys)
• Security systems (e.g. fire and intruder)
• Environmental control (e.g. heating and air-conditioning)
• Lighting control
• Home automation (e.g. home entertainment, doors, gates,
curtains and blinds)
• Automated meter reading (AMR) : automatically collecting
consumption, diagnostic, and status data from meter for billing
(facturation), troubleshooting (dépannage), and analyzing
• Industrial automation (e.g. plant monitoring and control)
21
JenNet Stack architecture and APIs
This part describes the JenNet software, which
comprises:
• JenNet stack software
• Application Programming Interfaces (APIs):
• Jenie API: This is the main function library used by an
application to interact with the JenNet stack
• JenNet API: This is a secondary function library for
advanced users who require low-level functions to
interact with the JenNet stack software
22
JenNet Stack : Architecture

23
 Jenie API : Types
The Jenie API includes two types of function :
• ‘Application to stack’ functions: These functions
are called in the application to interact with the
JenNet software stack. They are defined in the
Jenie API
• ‘Stack to application’ or ‘Callback’ functions:
These functions are called by the JenNet software
stack to interact with the application. Their
prototypes are included in the Jenie API but they
are user-defined, so you must define their
content in your application code.

24
 Jenie API : Functionality (1/2)
• Network Management Tasks :
• configure and initialize the network
• start a device as a Co-ordinator, Router or End Device
• determine whether (si) a Router or Coordinator is
accepting join requests
• advertise (annoncer) local node services and seek
(obtenir) remote node services
• establish bindings between local and remote node
services
• handle stack management events

25
 Jenie API : Functionality (2/2)
• Data Transfer Tasks:
• send data to a remote node or broadcast data to all
Router nodes
• send data to a bound service on a remote node
• handle stack data events
• System Tasks: The system functionality is largely
concerned with implementing sleep mode,
controlling the radio transmitter and dealing with
hardware events. These tasks include:
• configure and start sleep mode
• configure, start and stop the radio transmi er
• handle hardware events
26
The Hw architecture

27
JN5148 SoC Block Diagram

28
Modules based on JN5148

JN51xx Module with Standard UFL and SMA Connector

JN51xx Module with Integral Ceramic Antenna 29

Pin Configurations and circuit

30
31
 Porté radio
• Taking the ideal case of the two satellites,
assuming they both have antennae that
radiate equally in all directions with no losses,
the range between them is determined by
Equation below

32
 Porté radio
• Using approximate values for typical JN51xx module
performance measurements, we can calculate that
equipping the satellites with standard modules gives a
range of around 700 meters. Using high-power modules,
the increase in transmit power together with an
improvement in receive sensitivity pushes this range up
ten-fold to nearly 7 kilometers
• The above calculations are based on "free-space" radio
wave propagation (in a perfect vacuum (vide)) and use
antennae that are considered to be "isotropic" (radiate
equally in all directions). In reality, there are many real-
world issues that challenge these assumptions and a
different result may be obtained.

33
 Porté radio : cas de module Jennic
• Porté typique de 200 m pour un module standard
(autour de 0 dBm) dans une surface dégagée
• Pour une sortie de + que 15 dBm, la porté est
multiplier par 5
• Puissance en dBm = 10log(Po/Pr), où Pr = 1mw (dBw
 Pr = 1w)
• At the receive end of a radio link, the minimum power
level that can be detected is approximately
1/1000000000 of 1 mW (10 -9 mW or 10-12 W). Thus,
radio receivers require only a tiny amount of radio
energy to discern a usable signal. This factor is used to
excellent effect in a radio network.
34
 Communication radio 1/2
Techniques are provided by the underlying IEEE 802.15.4 stanard :
• Coding method : employed in the 2400-MHz band uses QPSK
(Quadrature Phase-Shift Keying) modulation with 250 Kb/s
(4bits/symbol, 62.5 Kbaud)
• there is a high probability that a message will get through to its
destination intact, even if there are conflicting transmissions (more
than one device transmitting in the same frequency channel at the
same time)
• Listen before send : The transmission scheme also avoids
transmitting data when there is activity on its chosen channel -
this is known as Carrier Sense, Multiple Access with Collision
Avoidance (CSMA-CA) (non-beacon)
• before beginning a transmission, a node will listen on the channel to
check whether it is clear. If activity is detected on the channel, the
node delays the transmission for a random amount of time and
listens again. If the channel is now clear, the transmission can begin,
otherwise the ‘delay and listen’ cycle is repeated
35
 Communication radio 2/2
• Acknowledgements : When a message arrives
at its destination, the receiving device sends
an acknowledgement to indicate that the
message has been received. If the sending
device does not receive an acknowledgement
within a certain time interval, it re-sends the
original message (it can re-send the message
several times until the message has been
acknowledged)
36
 Battery-Powered Components
• JenNet and IEEE 802.15.4 protocols are specifically designed for
battery-powered applications
• Low-capacity batteries  battery use must be optimised
• The major power drain in the system is when the radio
transceiver is operating
• data may be sent infrequently (perhaps once per hour or even per
week) which results in a low duty cycle
• when data is not being sent, the device reverts to a low-power sleep
mode
• Device can also potentially use "energy harvesting" to absorb
and store energy from its surroundings - for example, the use
of a solar cell panel
• In practice, not all devices in a network can be battery-
powered, particularly those that need to be switched on all the
time (and cannot sleep), such as Routers and Co-ordinators
37
Operational features and application
tasks

38
 Node Types

! The application on each node configures the host node as a Co-ordinator,

39
Router or End Device.
Network Topologies

40
 Adressage de noeuds
• Un nœud est adressé par son adresse MAC
• Adresse MAC = IEEE 64 bits
• Une dresse unique affectée au composant par le
fabriquant
• Fournit un ID unique pour le composant radio
• Nommé aussi adresse étendue
• JenNet l’utilise comme l’adresse réseau d’un
nœud

41
 Identification du réseau
• Un réseau JenNet est individuellement identifié (il n’y aura
pas de confusion avec des réseaux voisins) en utilisant deux
valeurs :
• Network Application ID (NA ID) : 32 bits, déterminé par le
développeur. Cette valeur utilisée dans l'application pour identifier le
réseau. Peut correspondre à un produit particulier d’un fabriquant
(exp. Système alarme). Par conséquent, le NA ID est commun pour
tous les réseaux basés sur le même produit et, dans ce sens, ce n'est
pas tout à fait unique
• PAN (Personal Area Network) ID: 16 bits, unique pour le réseau. Pré-
configuré par le développeur (≠ 0xFFFF), mais le coordinateur écoute
les PAN IDs des réseaux voisins pour vérifier si ce ID est unique.
• Si le ID n’est pas unique, le coordinateur incrémente automatiquement le
PAN ID, jusqu’à trouver une valeur unique
• Le PAN ID est utilisé pour les messages réseux de bas niveaux et non plus par
l’application
42
 Starting a Network
• ! A JenNet network uses the Network Application ID to
bring nodes together to form the network. Therefore, the
user applications of all nodes of the network must be
programmed with the same Network Application ID
• Starting a Network :
1. Radio Channel Selected
2. PAN ID Allocated
3. Network Application ID Obtained: The Co-ordinator obtains
the 32-bit Network Application ID from the local application
4. Network Ready for Joining: The Co-ordinator now ‘listens’
for requests from other nodes (Routers and End Devices) to
join the network

43
 Joining a Network (1/2)
1. Required Network Found:
• Router or End Device wishing to join the network first
scans the available channels to find operating networks
• To identify which network it should join, the node uses the
Network Application ID
2. Best Parent Selected:
• Initially, the Co-ordinator will be the only potential parent
of a new node
• If the network has partially formed, the node is able to
'see' the Co-ordinator and one or more Routers from the
network. In this case, it uses the following criteria, in the
given order of precedence, to choose its parent:

44
 Joining a Network (2/2)
a) Depth in tree (preference given to parent highest up the
tree)
b) Number of children (preference given to parent with
fewest children)
c) Signal strength (preference given to parent with strongest
signal)
3. Join Request Sent: The node then sends a
message to the selected parent (Co-ordinator or
Router), asking to join the network. The selected
parent determines whether it is can allow the
device to join, If this is the case, it accepts the
join request.

45
 Starting the Network (Co-ordinator only) (1/2)
• vJenie_CbConfigureNetwork() : allows network
parameters to be set, including those listed in the
following table :

46
Starting the Network : Table of Network param (2/2)

The parent will consider the Router child to be lost if it does not receive a ping or data
from the child within the period :
gJenie_MaxFailedPkts x gJenie_RouterPingPeriod x 100 ms 47
 Starting the Network
• teJenieStatusCode eJenie_Start (teJenieDeviceType
eDevType): The Co-ordinator, and therefore the
network, is then started by calling this function. it
specifies that the device to be started is the Co-
ordinator.

48
 eJenie_Start() (suite)

• These status responses are returned by most Jenie API function calls :

49
Starting Other Nodes (Routers and ED)
• vJenie_CbConfigureNetwork() : entry point for the
application code. Allows network parameters to be
set, including those listed in the table below :

50
51
 gJenie_EndDevicePingInterval
• A ping is generated just before going to sleep,
with a ping interval defined in terms of a number
of sleep cycles configured using the global
parameter gJenie_EndDevicePingInterval
(therefore the ping is not necessarily sent before
every sleep period). For this mechanism to work,
the End Device child must sleep/wake regularly
enough for the time between pings not to exceed
the value of
gJenie_EndDeviceChildActivityTimeout,
otherwise the parent will assume that the child is
lost.
52
Starting Other Nodes (Routers and ED)
• The device is then started by calling the
function eJenie_Start(). This function must
specify that the device is to be started as a
Router or an End Device

53
 Starting Other Nodes (Routers and ED)
• Once the device has been started, it will transmit beacon
requests to search for a parent in the network with a particular
Network Application ID. All potential parent nodes (Routers and
the Co-ordinator), which are in range, receive this request and
respond with beacons describing their ability to accept children.
• Given two or more responses from different potential parents, a
joining device will select the parent according to the set of criteria
described in page 23.
• If the device fails to find a parent, it will search again. After 9
failed attempts, it will generate a stack reset event
(E_JENIE_STACK_RESET) before repeating the scan process once
again (this event provides the application with an opportunity to
undertake any outstanding actions).
• After each failed attempt to find a parent, an End Device will
sleep (for the period gJenie_EndDeviceScanSleep) before the
next attempt. 54
APPLICATION STRUCTURE

This part outlines the code structure of a JenNet

application

55
 Application Code Overview

56
 Callbacks functions (1/5)
• Void vJenie_CbConfigureNetwork(void)
• entry point for the application code in the case of a
cold start (at system start-up or reset)
• void vJenie_CbInit(bool_t bWarmStart);
• specifying a cold or warm start. performs any
further initialization and then calls the function
eJenie_Start()

57
 Callbacks functions (2/5)
• void vJenie_CbMain(void);
• is the main application task. This function must
define any processing that is to be performed by
the application. Is called repeatedly by JenNet, but
between calls JenNet may generate events which
are sent to the application. The application must
define callback functions that can be called by
JenNet to deal with these events

58
 Callbacks functions (3/5)
• void vJenie_CbStackMgmtEvent (teJenieEventType
eEventType, void *pvEventPrim);
• this function deals with stack management events

59
 Callbacks functions (4/5)
• void vJenie_CbStackDataEvent (teJenieEventType
eEventType, void *pvEventPrim);
• this function deals with stack data events

60
 Callbacks functions (5/5)
• void vJenie_CbHwEvent(uint32 u32DeviceId,
uint32 u32ItemBitmap);
• The on-chip peripherals can be controlled using
the Integrated Peripherals API, described in the
Integrated Peripherals User Guide (JN-UG-3066).

61
 Data Transfer
• Using Addresses: Data is sent to the destination
node using the address of that node (the
address obtained from the service discovery
stage)
• Using Binding:
• See later …

62
Sending and Receiving Data using MAC
Addresses (1/3)
• Use of the function eJenie_SendData()
• The sent data arrives at the target node through
an E_JENIE_DATA event, received via the callback
function vJenie_CbStackDataEvent().

63
 Transferring Data (2/3)

• DestAddr have been previously obtained as the result of a Service

Discovery implemented using eJenie_RequestServices()
• A call to this function will (eventually) result in an E_JENIE_PACKET_SENT
or E_JENIE_PACKET_FAILED event to indicate the success or failure
(vJenie_CbStackMgmtEvent)
parameters description
u64DestAddr Address of the destination node. For a broadcast or to send
data to the Co-ordinator, this parameter must be set to zero
(for a broadcast, u8TxFlags must also be set to TXOPTION_BDCAST)
*pu8Payload Pointer to the data to be sent
u16Length Length of data to be sent, in bytes
u8TxFlags TXOPTION_ACKREQ, TXOPTION_BDCAST, TXOPTION_SILENT. The
values can be logical ORed to simultaneously specify more than
one option 64
Transferring Data (3/3): Length of data to
be sent in case of eJenie_SendData()

65
 Services (1/2)
• “Service” is a term used in Jenie to refer to a node property that can
provide and/or receive data, Examples of services are :
• Temperature sensor
• Light level sensor
• Keypad data entry
• LCD output
• Node can support up to 32 separate services
• Each service available in a network is identified by an ID number, between
1 and 32 (inclusive).
• The Service IDs are represented by bit positions in the network’s Service
Profile
• Two services must be compatible, i.e. one service must provide meaningful
data for the other service to interpret. For example:
• A temperature sensor and a hea ng controller are compa ble services
• A temperature sensor and a garage door controller are not compa ble
services
66
Services (2/2)

67
 Service Discovery
• Services allow a node to determine with which other
nodes it could possibly communicate
• For example, a heating control node may be interested in
nodes with a temperature sensor
• Service Discovery consists on :
• a node specifys to JenNet which services it supports
(registering services )
• a node requests all other nodes that support a particular
service (Requesting services)
• JenNet will then reply with the address of each appropriate node,
without additional effort by the application
• Service discovery is an essential step as the only way
for a node to obtain the addresses of the remote
nodes that provide the services it requires.
68
 Service Discovery : Registering Services (1/2)
• teJenieStatusCode eJenie_RegisterServices (uint32
u32Services) : Services are registered using this
function. The behaviour following this call is
dependent on the node type:
• Co-ordinator or Router: In this case, the services are
registered locally and the function call is able to return
immediately with success or failure
• End Device: In this case, the services must be registered
with the parent node and the function call returns with
deferred status, since this takes time. Once the services
have been registered with the parent, this is indicated by
means of an E_JENIE_REG_SVC_RSP response (management
stack event) received using the callback function
vJenie_CbStackMgmtEvent().
69
Service Discovery : Registering Services (2/2)

70
 Service Discovery : Requesting Services (1/2)

• teJenieStatusCode eJenie_RequestServices( uint32

u32Services bool_t bMatchAll) : This function is used
to find remote nodes that have the specified services.
The remote nodes will respond individually
• Returns almost immediately but will not be successful
until the network is up and running. Until the network
is up, the function will return the error code
E_JENIE_ERR_STACK_BUSY
• Responses from the remote nodes will be received as a
series of E_JENIE_SVC_REQ_RSP stack events via the
callback function vJenie_CbStackMgmtEvent().

71
 eJenie_RequestServices() (2/2)
• The responses contain the 64-bit IEEE/MAC address of
the relevant remote node and a 32-bit value detailing the
services supported by the node (where 1s indicate the
supported services). The application can then determine
with which node(s) it should communicate.

72
 Binding
• Normally for each communication, the address of the
target node must be specified. Alternatively, service
"binding" can be used which, once set up, allows
communication between two services to be
performed without the need to specify an address
• Binding associates a service on one node with a
service on another node. It is analogous to wiring a
cable between a sensor and an input on a control
unit

73
 Types of Binding

• consider a lighting control system:

• In the one-to-one case, a single switch controls a single light
• In the one-to-many case, a single switch controls several lights,
perhaps in the same room
• In the many-to-one case, several switches control a single light, such
as a light on a staircase (escalier), where there are switches at the top
and bottom of the stairs, either of which can be used to turn on the
light 74
 Binding Services API

• u64DestAddr and u8DestService could have been obtained

from an E_JENIE_SVC_REQ_RSP event received as the result
of a service request.
• You can bind a service to multiple remote services - this
requires separate calls to eJenie_BindService(). 75
 Transfering Data using bound services
(1/2)
• Use of the function
eJenie_SendDataToBoundService()
• The sent data arrives at the target node through an
E_JENIE_DATA_TO_SERVICE event, received via the
callback function vJenie_CbStackDataEvent().

76
 Transfering Data using bound services
(2/2)
parameters description
u8Service Service ID of local service from which data is to be sent
*pu8Payload Pointer to the data to be sent
u16Length Length of data to be sent, in bytes
u8TxFlags TXOPTION_ACKREQ, TXOPTION_BDCAST, TXOPTION_SILENT. The
values can be logical ORed to simultaneously specify more than
one option

• A call to this function will (eventually) result in an

E_JENIE_PACKET_SENT or E_JENIE_PACKET_FAILED event to indicate
the success or failure
• If security is disabled, the maximum data size is 74 bytes (u16Length)
• If security is enabled, the maximum data size is 53 bytes (u16Length)

77
 Security
• Encryption: To prevent external agents from
interpreting JenNet data messages, the data is
encrypted at the source and decrypted at the
destination using the same key - only devices with
the correct key can decrypt the encrypted data.
This feature is based on the AES (Advanced
Encryption Standard) CCM* algorithm, which is a
very high-security encryption system implemented
at the IEEE 802.15.4 level (and built into the
JN5148/JN5139 device as a hardware function)

78
 Security
• Integrity : This service adds a 128-bit Message Integrity Code
(MIC) to a message, which allows the detection of any
message tampering (falsification) by devices without the
correct encryption/decryption key
• Replay Attack Prevention : A nonce is used to protect against
replay attacks in which old messages are later re-sent to a
device. An example of a replay attack is someone recording
the open command for a garage door opener and then
replaying it to gain unauthorised entry into the garage
Nonce is some value that varies with time, although a very
large counter is sometimes used. A nonce can be a time
stamp, a visit counter on a Web page, or a special marker
intended to limit or prevent the unauthorized replay or
reproduction of a file
79
 Configuring Security
• teJenieStatusCode eJenie_SetSecurityKey (tsJenieSecKey
*pKey, uint64 u64Addr) : enables Security and specify
the security key
• On each call, the security key and 64-bit IEEE/MAC
address of the remote node are specified
• In the current software release, this function only needs to
be called once for communication with the whole network
=> MAC address is ignored in current release
• The function should be called from within the callback
function vJenie_CbInit() and should not be called from
within vJenie_CbConfigureNetwork().

80
 Receiving Data for an End Device
• ED may sleep and it should pool its parent on
waking from sleep when data is expected :
• Manual Polling
• Auto-Polling

81
 Data Polling (End Device Only) (1/2)
• An End Device can sleep for a good proportion of
the time in order to conserve power
• When data arrives for the ED from another node,
it may not be possible to deliver the data
immediately since the target node may be in
sleep mode
• The parent of the target node buffers the data
• It is the responsibility of the End Device to poll its
parent to check whether there is data waiting to be
delivered

82
 Data Polling (End Device Only) (2/2)

Caution: Pending data is buffered in the parent for a

maximum of 7 seconds and then, if uncollected, is
discarded. Failure by an End Device to poll for pending
data (donnée en attente) within this time limit can lead
to orphaning (rejection by its parent). 83
 Manual Polling
• The End Device can manually poll its parent for data
using eJenie_PollParent() function (auto-polling should
be disabled). Returns a status of E_JENIE_DEFERRED
• Following this function call, an E_JENIE_POLL_CMPLT
event is generated
• If there is pending data for the ED, this event contains a status
value of E_JENIE_POLL_DATA_READY and is followed by an
E_JENIE_DATA event containing the data

84
 Auto-Polling
• By default, an ED is configured to automatically poll its parent with a
period of 5 seconds, but this can be changed through the global
parameter gJenie_EndDevicePollPeriod, which can also be used to disable
auto-polling (by setting a polling period of 0)
• ED will automatically poll its parent on waking from sleep, irrespective of
the polling period set
• If you set the sleep period using eJenie_SetSleepPeriod() < than the
polling period defined in gJenie_EndDevicePollPeriod, the End Device will
poll the parent more often than configured through this global parameter
• Only one data message will be delivered on each auto-poll. In order to
collect any other pending data messages the application could then
perform repeated manual polls using the eJenie_PollParent()

85
 Losing a parent : auto-ping
• A node may lose its parent and be unaware of this loss,
particularly if data exchanges with its parent are infrequent
• In JenNet, an auto-ping mechanism (enabled by default) is
employed to periodically verify that the parent node is still
present. On each ping, the node sends a message to its parent:
• If the parent is still present and accepts the node as its child, it sends
a response
• If the parent is not present, no response is sent. After a certain
number (five, by default) of consecutive unacknowledged pings, the
child considers its parent to be lost and attempts to re-join the
network
• If the parent is present but has dis-owned the child, an "Unknown-
Node" message is sent back. In this case, the child will attempt to re-
join the network

86
 Losing a Child Node (cas de ED)

• Buffered message restrictions : (Rappel)

• A total of 12 message buffers in the parent are used for
this purpose - 4 of these are 802.15.4 MAC buffers and 8
are JenNet buffers
• Pending data is buffered in the parent for a maximum of 7
seconds and then, if uncollected, is discarded

87
Losing a Child Node (cas de Router)
The parent will consider the Router child to be lost if
it does not receive a ping or data from the child
within the period defined by the product :

88
 Sleep Mode (EDs Only) (1/3)
• teJenieStatusCode eJenie_Sleep
(teJenNetSleepMode eSleepMode);
• must be called from vJenie_CbMain() only (and
from no other callback function)
• The following sleep options can be specified:
• with or without the 32-kHz on-chip oscillator running
• with or without preserving the contents of on-chip
RAM (memory held)

89
 Sleep Mode (EDs Only) (2/3)
• The wake methods can be :
• the on-chip wake timers, for which the 32-kHz
oscillator must be running during sleep
• events deriving from the on-chip comparators or DIOs
• The device can be pre-configured to sleep for a
fixed duration, set using the function
eJenie_SetSleepPeriod()

90
 Sleep Mode (EDs Only) (3/3)
• teJenieStatusCode eJenie_SetSleepPeriod (uint32
u32SleepPeriodMs);

• In ‘deep sleep’ mode, all switchable power domains are

powered off and the 32-kHz oscillator is stopped. This
mode can only be exited by :
• power cycling (switching off then on) or
• resetting the chip (a DIO event can be used to trigger a reset)

91
 Sleep Mode with Memory Held
• On-chip RAM will remain powered during sleep and
therefore context data will be preserved. This allows
the node to easily resume network operation when it
exits sleep mode. When the node wakes from sleep
with memory held, the stack calls the user-defined
callback function Jenie_CbInit() which should initiate
a ‘warm restart’. The device does not re-join the
network immediately but remains in the idle state
until eJenie_Start() is called. The device then restarts
as a network node using the context data held in on-
chip RAM.
• Remark : context data describes the current state of the
network and application
92
 Sleep Mode without Memory Held
• On-chip RAM is powered down during sleep
• Context data held in RAM must be saved to external non-
volatile memory (e.g. Flash) before calling eJenie_Sleep().
This data can be saved using the function
JPDM_SaveContext() which saves the network and the
application context
• When the node wakes from sleep without memory held, the
stack calls the user defined callback function vJenie_CbInit()
which should initiate a ‘cold restart’
• vJenie_CbInit() must call the function eJPDM_RestoreContext()
(before calling eJenie_Start()) to retrieve the application context
data stored in non-volatile memory before entering sleep. The
network context data will be retrieved automatically (only if the
global parameter gJenie_RecoverFromJpdm has been set)
93
 Sleep Mode without Memory Held
• The device does not re-join the network
immediately but remains in the idle state until
eJenie_Start() is called. The device then restarts
as a network node using the context data that
has been re-loaded into on-chip RAM
• While in the idle state, vJenie_CbMain() is
regularly called by the network stack, so that
other necessary tasks can be performed

94
 Saving and Restoring Context Data (1/3)
• Two Jenie API functions are provided for this purpose:
• vJPDM_SaveContext(): This function saves both network and
application context to non-volatile memory so data can be
recovered following a power failure or sleep without memory
held. It must only be called in the main loop callback function,
vJenie_CbMain(), and must not be called in event handling
callback functions
• To enable save/restore of network context, the global parameter
gJenie_RecoverFromJpdm must be set to TRUE within the callback
function vJenie_CbConfigureNetwork(). The saved data will then be
automatically recovered when the stack is re-started using eJenie_Start()
• eJPDM_RestoreContext(): This function is used to recover
application context from non-volatile memory (network context
can be recovered automatically). The first time the application is
run, the function registers a buffer in on-chip memory where the
application context data will be stored - this buffer is set up
using the macro JPDM_DECLARE_BUFFER_DESCRIPTION
95
 Saving and Restoring Context Data
(2/3)

• teJenieStatusCode eJPDM_RestoreContext
(tsJPDM_BufferDescription *psDescription);

96
Saving and Restoring Context Data (3/3)

97