wdiff draft-ietf-lpwan-schc-over-sigfox-01.txt draft-ietf-lpwan-schc-over-sigfox-02.txt

lpwan Working Group JC. Zuniga
Internet-Draft SIGFOX
Intended status: Informational C. Gomez
Expires: May 7, November 16, 2020 Universitat Politecnica de Catalunya
L. Toutain
IMT-Atlantique
November 4, 2019
May 15, 2020

SCHC over Sigfox LPWAN
draft-ietf-lpwan-schc-over-sigfox-01
draft-ietf-lpwan-schc-over-sigfox-02

Abstract

The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification describes
a both, an application
header compression scheme scheme, and a frame fragmentation and loss
recovery functionality for Low Power Wide Area Network (LPWAN)
technologies. SCHC offers a great level of flexibility that can be
tailored for different LPWAN technologies.

The present document provides the optimal parameters and modes of
operation when SCHC is implemented over a Sigfox LPWAN. This set of
parameters are also known as a "SCHC over Sigfox profile."

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 7, November 16, 2020.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SCHC: Generic Framework for Static Context Header Compression
and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3
4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4 3
4.1. SCHC Rules Network Architecture . . . . . . . . . . . . . . . . . . 3
4.2. Uplink . . . . . 4
4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 5
5. Fragmentation
4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Fragmentation headers 6
4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . 5
5.2. Uplink fragment transmissions . . . 6
4.5. Fragmentation . . . . . . . . . . . 5
5.2.1. . . . . . . . . . . . 7
4.5.1. Uplink No-ACK mode Fragmentation . . . . . . . . . . . . . . . . 7
4.5.2. Downlink Fragmentation . 5
5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . 10
4.6. Padding . 6
5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6
5.3. Downlink fragment transmissions . . . . . . . . . . 11
5. Security considerations . . . 8
6. Padding . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 . 11
7. Security considerations References . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
9. 12
7.2. Informative References . . . . . . . . . . . . . . . . . . . 10 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 12

1. Introduction

The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification
[I-D.ietf-lpwan-ipv6-static-context-hc] [RFC8724] defines both, a higher
layer header compression scheme and a fragmentation and loss recovery
functionality. Both can be used on top of all the LWPAN systems
defined in [RFC8376] . These LPWAN systems have similar
characteristics such as star-oriented topologies, network
architecture, connected devices with built-in applications, etc.

SCHC offers a great level of flexibility to accommodate all these
LPWAN systems. Even though there are a great number of similarities
between LPWAN technologies, some differences exist with respect to
the transmission characteristics, payload sizes, etc. Hence, there
are optimal parameters and modes of operation that can be used when
SCHC is used on top of a specific LPWAN.

This document describes the recommended parameters parameters, settings and
modes of operation to be used when SCHC is implemented over a Sigfox
LPWAN. This set of parameters are also known as a "SCHC over Sigfox
profile."

2. Terminology

It is assumed that the reader is familiar with the terms and
mechanisms defined in [RFC8376] and in
[I-D.ietf-lpwan-ipv6-static-context-hc]. [RFC8724].

3. SCHC: Generic Framework for Static Context Header Compression and
Fragmentation

The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) described in
[I-D.ietf-lpwan-ipv6-static-context-hc] [RFC8724] takes advantage of the
predictability of data flows existing in LPWAN networks to avoid
context synchronization. Nonetheless, these contexts

Contexts must be stored and configured pre-configured on both ends. This can be
done either by using a provisioning protocol, by out of band means,
or by pre-provisioning them (for instance (e.g. at manufacturing time). The way the
contexts are configured and stored on both ends is out of the scope
of this document.

Dev App

4. SCHC over Sigfox

4.1. Network Architecture

Figure 1 represents the architecture for compression/decompression
(C/D) and fragmentation/reassembly (F/R) based on the terminology
defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base
Station and the Network Gateway (NGW) is the Sigfox cloud-based
Network.

Device Application
+----------------+ +--------------+
| APP1 APP2 APP3 | |APP1 APP2 APP3|
+----------------+ +--------------+
| UDP | | | | UDP |
| IPv6 | | | | IPv6 |
+--------+ | | +--------+
|
|SCHC SCHC C/D and F/R| & F/R | | |
| | |
+--------+-------+ +-------+------+ |
+-------+--------+ +--------+-----+
$ +--+ +----+ +-----------+ .
$ +---------+ +--------------+ +---------+ .
+~~ |RG| === |NGW |Sigfox BS| |Sigfox Network| | SCHC | .
| (RG) | === | SCHC |... Internet ..
+--+ +----+ (NGW) | === |F/R and C/D|
+-----------+ & C/D|.....
+---------+ +--------------+ +---------+

Figure 1: Network Architecture

Figure 1 represents

In the architecture for compression/decompression
and fragmentation/reassembly, which is based on [RFC8376]
terminology, where case of the Radio Gateway is a global Sigfox Network, RGs (or Base Station and Stations) are
distributed over multiple countries wherever the
Network Gateway Sigfox LPWAN service
is the provided. The NGW (or cloud-based Sigfox Cloud. Core Network) is a
single entity that connects to all Sigfox base stations in the world,
providing hence a global single star network topology.

The Device is sending applications flows that are compressed and/or
fragmented by a Static Context Header Compression Compressor/
Decompressor SCHC Compressor/Decompressor (SCHC C/D) C/D + F/R) to
reduce headers size and/or fragment the packet. The resulting information SCHC
Message is sent over a layer two (L2) Sigfox frame to a LPWAN Radio Gateway (RG) the Sigfox Base
Stations, which forwards then forward the frame SCHC Message to a the Network Gateway
(NGW).

4. SCHC over Sigfox

In The NGW then delivers the case of SCHC Message and associated
gathered metadata to the global Network SCHC C/D + F/R.

The Sigfox network, RGs (or base stations) are
distributed over Network (NGW) communicates with the multiple countries where Network SCHC C/D + F/R
for compression/decompression and/or for fragmentation/reassembly.
The Network SCHC C/D + F/R share the Sigfox LPWAN
service is provided. On same set of rules as the other hand, Dev
SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with
the NGW (or Cloud-based Core
network) is or it could be located in a single entity that connects different place, as long as a
tunnel or secured communication is established between the NGW and
the SCHC C/D + F/R functions. After decompression and/or reassembly,
the packet can be forwarded over the Internet to all Sigfox base stations
in one (or several)
LPWAN Application Server(s) (App).

The SCHC C/D + F/R processes are bidirectional, so the world. same
principles are applicable on both uplink and downlink.

4.2. Uplink

Uplink Sigfox transmissions occur in repetitions over different times
and frequencies. Besides these time and frequency diversities, the
Sigfox network also provides space diversity, as potentially an
uplink message will be received by several base stations.

Since all messages are self-contained and base stations forward them
all back to the same Core network (NGW), Network, multiple input copies can be
combined at the NGW and hence provide for extra reliability based on
the triple diversity (i.e. time, space and frequency).

A detailed description of the Sigfox Radio Protocol can be found in
[sigfox-spec].

Messages sent from the Device to the Network are delivered by the
Sigfox network (NGW) to the Network SCHC C/D + F/R through a
callback/API with the following information:

o Device ID

o Message Sequence Number

o Message Payload

o Message Timestamp

o Device Geolocation (optional)

o RSSI (optional)

o Device Temperature (optional)

o Device Battery Voltage (optional)

The Device ID is a globally unique identifier assigned to the Device,
which is included in the Sigfox header of every message. The Message
Sequence Number is a monotonically increasing number identifying the
specific transmission of this uplink message, and it is part of the
Sigfox header. The Message Payload corresponds to the payload that
the Device has sent in the uplink transmission.

The Message Timestamp, Device Geolocation, RSSI, Device Temperature
and Device Battery Voltage are metadata parameters provided by the
Network.

A detailed description of the Sigfox callbacks/APIs can be found in
[sigfox-callbacks].

Only messages that have passed the L2 Cyclic Redundancy Check (CRC)
at network reception are delivered by the Sigfox Network to the
Network SCHC C/D + F/R.

+---------------+-----------------+
| Sigfox Header | Sigfox payload |
+---------------+---------------- +
| SCHC message |
+-----------------+

Figure 2: SCHC Message in Sigfox

Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC
Message could be a SCHC Packet (e.g. compressed) or a SCHC Fragment
(e.g. a piece of a bigger SCHC Packet).

4.3. Downlink

Downlink transmissions are Device-driven and can only take place after
following an uplink communication. A device Hence, a Device willing to
receive downlink messages indicates so to the network in the
preceding uplink message with a downlink request flag, and then it
opens a fixed window for downlink reception after the uplink
transmission. The delay and duration of this the reception window have
fixed values. If there is a downlink message to be sent for this
given device Device (e.g. either a response to the uplink message or queued information),
information waiting to be transmitted), the network transmits it to
the Device during the reception window.

When a downlink message is sent to a Device, an acknowledgement is
generated by the Device through the Sigfox protocol and reported by
the Sigfox Network. This acknowledgement can be retrieved through
callbacks by the customer.

A detailed description of the Sigfox Radio Protocol can be found in
[sigfox-spec].

The NGW communicates with the Network SCHC C/D + F/R for compression/
decompression and/or for fragmentation/reassembly. The Network SCHC
C/D + F/R share the same set
[sigfox-spec] and a detailed description of rules as the Dev SCHC C/D + F/R. The
Network SCHC C/D + F/R Sigfox callbacks/APIs
can be collocated with the NGW or it could be found in another place, as long as a tunnel is established between the NGW
and the SCHC C/D + F/R functions. After decompression and/or
reassembly, the packet can be forwarded over the Internet to one (or
several) LPWAN Application Server(s) (App).

The SCHC C/D + F/R processes are bidirectional, so the same
principles can be applied on both uplink and downlink.

4.1. [sigfox-callbacks].

4.4. SCHC Rules

The RuleID MUST be sent at the beginning of included in the SCHC header. The total number of
rules to be used affects directly the Rule ID field size, and
therefore the total size of the fragmentation header. For this
reason, it is recommended to keep the number of rules that are
defined for a specific device to the minimum possible.

4.2. Packet processing

TBD

4.5. Fragmentation

The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] [RFC8724] defines a generic fragmentation
functionality that allows sending data packets or files larger than
the maximum size of a Sigfox data frame. The functionality also
defines a mechanism to send reliably multiple messages, by allowing
to resend selectively any lost fragments.

The SCHC fragmentation supports several modes of operation. These
modes have different advantages and disadvantages depending on the
specifics of the underlying LPWAN technology and application Use
Case. This section describes how the SCHC fragmentation
functionality should optimally be implemented when used over a Sigfox
LPWAN for the most typical use case Use Case applications.

5.1.

4.5.1. Uplink Fragmentation headers

A list of fragmentation header fields, their sizes as well as
suggested modes for SCHC fragmentation over

Sigfox are provided in
this section.

5.2. Uplink fragment transmissions

Uplink uplink transmissions are completely asynchronous and can take
place in any random frequency of the allowed uplink bandwidth
allocation. Hence, devices can go to deep sleep mode, and then wake
up and transmit whenever there is a need to send any information to
the network. In that way, there is no need to perform any network
attachment, synchronization, or other procedure before transmitting a
data packet. All data packets are self contained self-contained with all the
required information for the network to process them accordingly.

Since uplink transmissions occur asynchronously, an SCHC fragment can
be transmitted at any given time by the Dev.

5.2.1. Device. Sigfox uplink
messages are fixed in size, and as described in [RFC8376] they can
carry 0-12 bytes payload. Hence, a single SCHC Tile size per mode
can be defined so that every Sigfox message always carries one SCHC
Tile.

4.5.1.1. Uplink No-ACK mode Mode

No-ACK is RECOMMENDED to be used for transmitting short, non-critical
packets that require fragmentation and do not require full
reliability. This mode can be used by uplink-only devices that do
not support downlink communications, or by bidirectional devices when
they send non-critical data.

The recommended RECOMMENDED Fragmentation Header size is 8 bits, and it is
composed as follows:

The recommended Rule ID size is: 2

o RuleID size: 4 bits

The recommended

o DTag size (T) is: 2 (T): 0 bits
o Fragment Compressed Number (FCN) size (N): 4 bits

o As per [I-D.ietf-lpwan-ipv6-static-context-hc], [RFC8724], in the No-ACK mode the W (window) field is not
present.

When fragmentation is used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits

When fragmentation is

o RCS: Not used to transport non-IP frames, the Message
Integrity Check (MIC) size, M: TBD bits

The algorithm for computing the MIC field MUST be TBD.

5.2.2. Uplink ACK-Always mode

TBD

5.2.3.

4.5.1.2. Uplink ACK-on-Error mode Mode: Single-byte SCHC Header

ACK-on-Error with single-byte header is RECOMMENDED for larger medium-large
size packets that need to be sent reliably. This mode ACK-on-Error is optimal
for Sigfox transmissions, since it leads to a reduced number of ACKs
in the lower capacity downlink
channel and channel. Also, downlink messages can
be sent asynchronously and opportunistically.

o Single-byte SCHC UL header

In the most generic case, and allowing

Allowing transmission of packets/files up to 300 bytes long, the SCHC
uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size
and is composed as follows:

o Rule ID size is: 2 bits. size: 3 bits

o DTag size (T) is: 1 bit. (T): 0 bits

o Window index (W) size is: (M): 2 bits. bits

o Fragment Compressed Number (FCN) size (N): 3 bits.

For the ACK-on-Error fragmentation mode(s), a single window size
is RECOMMENDED. bits

o MAX_ACK_REQUESTS: 3.

MAX_WIND_FCN: 6 (or 0b110, which allows 5

o WINDOW_SIZE: 7 (with a maximum window size value of 7
fragments). FCN=0b110)

o Tile size: 11 bytes

o Retransmission Timer: 45 sec. Application-dependent

o Inactivity Timer: [use case dependent].

When fragmentation is Application-dependent

o RCS: Not used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits

The algorithm for computing the MIC field MUST be TBD.

The correspondent SCHC ACK in the downlink is 13 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload.

4.5.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC UL Header

ACK-on-Error with two-byte header is RECOMMENDED for very large size
packets that need to be sent reliably. ACK-on-Error is optimal for
Sigfox transmissions, since it leads to a reduced number of ACKs in
the lower capacity downlink channel. Also, downlink messages can be
sent asynchronously and opportunistically.

In order to allow transmission of very large packets/files up to 2250
bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED
to be 16 bits in size and composed as follows:

o Rule ID size is: 4 bits. 8 bits

o DTag size (T) is: 4 bit. 0 bits

o Window index (W) size is: (M): 3 bits. bits

o Fragment Compressed Number (FCN) size (N): 5 bits.

For the ACK-on-Error fragmentation mode(s), a single window size
is RECOMMENDED.

o MAX_ACK_REQUESTS: 3. 5

o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)

o Tile size: 10 bytes

o Retransmission Timer: 45 sec. Application-dependent

o Inactivity Timer: [use case dependent].

When fragmentation is Application-dependent

o RCS: Not used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits

The algorithm for computing the MIC field MUST be TBD.

The correspondent SCHC ACK in the downlink is 43 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload.

5.3. Downlink

4.5.1.4. All-1 behaviour + Sigfox Sequence Number

For ACK-on-Error, as defined in [RFC8724] it is expected that the
last SCHC fragment transmissions of the last window will always be delivered with
an All-1 FCN. Since this last window may not be full (i.e. it may be
comprised of less than WINDOW_SIZE fragments), an All-1 fragment may
follow a value of FCN higher than 1 (0b01). In this case, the
receiver could not derive from the FCN values alone whether there are
any missing fragments right before the All-1 fragment or not.

However, since a Message Sequence Number is provided by the Sigfox
protocol together with the Sigfox Payload, the receiver can detect if
there are missing fragments before the All-1 and hence construct the
corresponding SCHC ACK Bitmap accordingly.

4.5.2. Downlink Fragmentation

In some LPWAN technologies, as part of energy-saving techniques,
downlink transmission is only possible immediately after an uplink
transmission. This allows the device to go in a very deep sleep mode
and preserve battery, without the need to listen to any information
from the network. This is the case for Sigfox-enabled devices, which
can only listen to downlink communications after performing an uplink
transmission and requesting a downlink.

When there are fragments to be transmitted in the downlink, an uplink
message is required to trigger the downlink communication. In order
to avoid potentially high delay for fragmented datagram transmission
in the downlink, the fragment receiver MAY perform an uplink
transmission as soon as possible after reception of a downlink
fragment that is not the last one. Such uplink transmission MAY be
triggered by sending a SCHC message, such as a SCHC ACK. However,
other data messages can equally be used to trigger DL communications.

Sigfox downlink messages are fixed in size, and as described in
[RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC
Tile size per mode can be defined so that every Sigfox message always
carries one SCHC Tile.

For reliable downlink fragment transmission, the ACK-Always mode is
RECOMMENDED.

The recommended SCHC downlink Fragmentation Header size is: is RECOMMENDED to be 8
bits

The recommended Rule ID in size is: 2 bits.

The recommended and is composed as follows:

o RuleID size: 3 bits

o DTag size (T) (T): 0 bits

o Window index (W) size (M) is: 2 bits. 0 bits

o Fragment Compressed Number (FCN) size (N): 3 bits.

As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the ACK-Always
mode a Window (W) 1-bit field must be present.

For the ACK-Always fragmentation mode(s), a single window size is
RECOMMENDED.

The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of
MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows 5 bits

o MAX_ACK_REQUESTS: 5

o WINDOW_SIZE: 31 (with a maximum window
size value of FCN=0b11110)

o Tile size: 7 fragments).

When fragmentation is used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits

The algorithm for computing the MIC field MUST be TBD.

Sigfox downlink frames have a fixed length of 8 bytes, which means
that default SCHC algorithm for padding cannot be used. Therefore,
the 3 last bits of the fragmentation header are used to indicate in bytes the size of the padding. A size of 000 means that the full
ramaining frame is

o Retransmission Timer: Application-dependent

o Inactivity Timer: Application-dependent
o RCS: Not used to carry payload, a value of 001 indicates
that the last byte contains padding, and so on.

4.6. Padding

The Sigfox payload fields have different characteristics in uplink
and downlink.

Uplink frames can contain a payload size from 0 to 96 bits, that is 0
to 12 bytes. The
radio protocol allows sending zero bits or bits, one single bit of
information for binary applications (e.g. status), or an integer
number of bytes. Therefore, for 2 or more bits of payload it is
required to add padding to the next integer number of bytes. The
reason for this flexibility is to optimize transmission time and
hence save battery consumption at the device.

Downlink frames on the other hand have a fixed length. The payload
length must be 64 bits (i.e. 8 bytes). Hence, if less information
bits are to be transmitted, padding would be necessary and it should
be performed as described in the previous section.

7. necessary.

5. Security considerations

The radio protocol authenticates and ensures the integrity of each
message. This is achieved by using a unique device ID and an AES-128
based message authentication code, ensuring that the message has been
generated and sent by the device with the ID claimed in the message.

Application data can be encrypted at the application level or not,
depending on the criticality of the use case. This flexibility
allows providing a balance between cost and effort vs. risk. AES-128
in counter mode is used for encryption. Cryptographic keys are
independent for each device. These keys are associated with the
device ID and separate integrity and confidentiality keys are pre-
provisioned. A confidentiality key is only provisioned if
confidentiality is to be used.

The radio protocol has protections against reply attacks, and the
cloud-based core network provides firewalling protection against
undesired incoming communications.

6. Acknowledgements

Carles Gomez has been funded in part by the ERDF and the Spanish
Government through project TEC2016-79988-P.

9. Informative References

[I-D.ietf-lpwan-ipv6-static-context-hc]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "LPWAN Static Context Header Compression (SCHC)

The authors would like to thank Diego Wistuba, Clement Mannequin and fragmentation
Sandra Cespedes for IPv6 their useful comments and UDP", draft-ietf-lpwan-
ipv6-static-context-hc-17 (work in progress), October
2018. design considerations.

7. References

7.1. Normative References

[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.

[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.

7.2. Informative References

[sigfox-callbacks]
Sigfox, "Sigfox Callbacks",
<https://support.sigfox.com/docs/callbacks-documentation>.

[sigfox-spec]
Sigfox, "Sigfox Radio Specifications",
<https://build.sigfox.com/sigfox-device-radio-
specifications>.

Authors' Addresses

Juan Carlos Zuniga
SIGFOX
425 rue Jean Rostand
Labege 31670
France

Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/

Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain

Email: carlesgo@entel.upc.edu
Laurent Toutain
IMT-Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France

Email: Laurent.Toutain@imt-atlantique.fr