FIELD OF THE INVENTION

The present invention relates generally to the field of the Internet of Things, and more particularly to: a common core multi-role Internet of Things communication module; a universal module architecture for the Internet of Things; a method for initializing, configuring and operating on embedded resources within the common core multi-role module; a homogeneous communication interface integrated into the universal module architecture of the Internet of Things; a distributed intelligence for gateway selection within a wireless mesh network; and a multi-application network architecture.

BACKGROUND OF THE INVENTION

Module architecture for the Internet of Things

There are more and more communication modules designed for the Internet of Things. However, only a few of those modules are fulfilling the real industry needs, with performance, security and robustness in mind. Additionally, the Industrial Internet of Things focuses more on business operations using companies' private networks with integration within their existing IT infrastructure. Easiness of interaction with Internet of Things devices disseminated through the companies' infrastructures is therefore of primary concern. However, most of the nowadays Internet of Things modules can only manage a single communication interface. This single interface imposes severe limitations in terms of easiness of installation and maintenance; installation and maintenance requiring multiple possibilities to access a device through different channels (eg. machine-to-machine and personnel-to-machine communication channels). This mono-interface design of most Internet of Things devices traces back to the original Internet of Things paradigm where the devices were conceived as battery operated devices with constrained resources and with the obsession to minimize the power consumption. With the advent of more and more powerful microcontrollers, yet very low power or ultra-low-power, the concern of restricting an Internet of Things device with a single network interface becomes less and less justified. Furthermore, most of industrial machines are wired powered and Internet of Things devices attached to those machines can be wired powered.

In general, state-of-the-art Internet of Things modules are part of the following models of architecture:

Model 1 : In this first model, modules for Internet of Things communication support only a single communication interface with a firmware closed, which means that client applications cannot be installed in the embedded processor and that only the application developed by the module manufacturer can be executed. We also refer to this as a proprietary firmware.

Model 2: In this second model, we consider modules for the Internet of Things that have a single communication interface with an open source software. This means that client applications can be installed within the communication module directly.

Model 3: In this third model, Internet of Things modules are able to manage multiple communication interfaces with a closed software. This means that the firmware is proprietary to the module manufacturer. Moreover, this model also considers that the communication interfaces are on the module itself.

Model 4: In this fourth model, we consider Internet of Things modules with multiple communication interfaces capabilities and open local firmware. This means that client applications can be installed into the module's processor.

However, these existing approaches to design Internet of Things communication module suffer from various limitations in the Industrial Internet of Things paradigm.

Firstly, and for example, integrating customer applications within the communication module must be done very carefully because of the shared processing resources between the communication and the customer applications. This implies that the communication can interfere with the industrial processing. Moreover, communications are by nature asynchronous while industrial systems operations require precise timings, which can be synchronous or asynchronous. There is therefore a need to protect the industrial-oriented processing from the Internet of Things paradigm processing.

Secondly, the Internet of Things modules that can host client application are more complex to interface with a dedicated client processor connected to the Internet of Things module. Moreover, the Internet of Things module development tools are not necessarily the tools usually used by the object manufacturer. Consequently, connecting an object to the Internet will be harder than simply integrate a communication module that is supposed to do everything to manage the connection, and will require more effort to get the system up and running from end-to-end because specific interaction library must be written between the client processor and the Internet of Things module or a new development environment and embedded system has to be used by the object manufacturer to develop its connected object.

Thirdly, the security of an Industrial Internet of Things application must be vertical in the sense that a) the physical communication must be secured, b) the network must be secured, and c) the applications must be secured as well. This implies that a software stack shared between a client processor and a communication module is harder to secure because the application will be on the client processor while the network and physical communications will be managed by the communication module. In addition, the security provided by Internet of Things module relies on static parameters, usually predefined at factory or flashed during commissioning, and which protect the physical communication channels using symmetric cryptography. It is rare that a communication module features asymmetric cryptography because such a security infrastructure generally rely on a central management system. There are only a few companies in the world providing both the hardware and software components to build a coherent end-to-end industrial Internet of Things application. The device management and network management are real weaknesses in today's Internet of Things platforms, because a) those platforms are based on the assumption that web technologies are generic enough to avoid taking risks, or b) simply because those platforms are not based upon hardware and firmware that match the software platform architecture.

In addition, about security, in the industrial Internet of Things paradigm, the connected objects are expected to be part of a company infrastructure and potentially interact with business processes and people. To keep the security strong, this will force the security officer in charge of the integration of the industrial Internet of Things applications to introduce and adapt the company's security policies. It is therefore mandatory to have strong and various security mechanisms embedded into an industrial Internet of Things communication module to match the security policies of companies.

About the connected object firmware, the Internet of Things community has proposed plenty of open source operating systems that come with multiple communication interfaces support and some applications. The major difference is that although these applications are available in the communication module, the data formatting is still managed by the external client system or internal client application. This forces the connected object manufacturer to develop data management services, connection managers and formatting helpers to support its application, as well as developing the remote software counter-part. Finally, most of the software available in the community is not professional-grade with partial implementation of standardized protocols and incoherent design strategy. Moreover, the open source Internet of Things community really lacks in good documentation and stability. It is not possible for an industry to rely on the today's open source implementation of the Internet of Things for a professional and reliable application.

Internet of Things architectures

Referring to figure 6, the Internet of Things architectures using active connected objects, typically through a wireless mesh network, include an information system infrastructure 3001 , a connection 3002 3007 towards at least one gateway 3003, at least one connected object 3005 interfacing with the gateway 3003. The general approach for developing gateways 3003 for the Internet of Things uses powerful systems. These powerful systems usually operate on a processor running a Linux operating system or similar class of operating system like Microsoft Windows. The Internet of Things nodes 3005 are using very different systems based on microcontroller rather than powerful processors. A microcontroller is a chip including a processor with small processing capabilities and a set of peripherals ranging from the random access memory (RAM), read-only memory (ROM) and general input/output pins. It is therefore not easy for a microcontroller to have extended RAM capabilities while a processor has most of its resources external to it. Moreover, the microcontroller clock frequencies are lower than processor's clock frequencies running Linux operating systems or similar. What can be noticed with these Internet of Things architectures is that there is a mismatch in the securities and integration of Internet of Things nodes 3005 within the IT infrastructure 3001 due to the heterogeneity of those different systems. For example, the vast majority of the Internet of Things node 3005 security is based on static symmetric cryptography only.

The Internet of Things architectures presented here are used to describe the positioning of the proposed invention. We distinguish three kinds of Internet of Things architectures that use servers and connected objects. A connected object is composed of two main parts. The first part is the business part of the object, and the second part is the connecting capability of the object itself. For example, a connected temperature sensor has in the business part the sensor and the logic to measure the temperature and in the communication part the connecting capabilities to transmit information toward a network. In most cases, the communication capability of an object will be integrated within a communication electronic module soldered on the object main printed circuit board. The server side is also composed of different parts and is usually more complex than a single server; it can be seen as a public or private cloud infrastructure with a set of IT services. For instance, there are both the business logic and business user interfaces that usually reside in specific services. Then, there are some generic components that could be mutualized into a dedicated middleware for connected object management.

On the server part of the architecture, there are roughly the following generic components that need to be integrated: data management, format parsers, resources management, services, security, business logic, and a user interface.

On the object part of the architecture, there are almost the same components that need to be integrated within the device. In addition to the server components, there are the data acquisition, the networking and communication interfaces management.

Referring to the figure 7, the proposed approach is to design an Internet of Things module 3052 with part of the capabilities of the system used for gateways 3051 and part of the capabilities of the systems used for constrained devices or Internet of Things nodes 3053. Gateway systems 3051 are more likely to be compared to computers 3050 like desktops or laptops. Computer class 3050 of systems usually uses processor with more than 1 GHz clock frequencies, memories of gigabytes and power consumptions of tens of watts. Gateways 3051 can be categorized as belonging to an embedded computer class, with lower frequencies in the range of hundreds of megahertz up to a couple of gigahertz for modern embedded processors. Very constrained device class 3053 tends to represent the Internet of Things typical node architecture, which is more likely to use microcontrollers with clock frequencies below one hundred megahertz. The available memories within this very constrained device class 3053 are about tens to a couple of hundreds of kilobytes. The proposed approach 3052 uses large microcontrollers with extended capabilities, running at frequencies around one hundred megahertz and with memory going in the range of several hundreds of kilobytes.

As a result and referring now to the figure 8, the network of connected objects, including the gateways 3102 and the Internet of Things nodes 3104 is now based on the same module. This brings a coherent security policy throughout the infrastructure, from the IT infrastructure 3100 towards the Internet of Things node 3104. We call this kind of module a multi-role Internet of Things communication module because it can be used either at the gateway level 3102, or at the Internet of Things constrained node level 3104 seamlessly. The IT infrastructure 3100 can be therefore connected to a multi-role Internet of Things communication module acting as a gateway 3102 using standard Internet-compliant 3101 communication interfaces 3105. Beside the security aspects, this approach also increases the application interoperability between systems because they are all having the same capabilities in terms of processing.

A multi-role Internet of Things communication module that can act as a gateway or an Internet of Things node is inevitably able to manage multiple communication interfaces. However, not all these communication interfaces are always necessary; they are depending on the final role of the module when installed in a client system. Referring to the figure 10 and 9, the multi-role Internet of Things communication module 8703 is expected to be soldered on a client system 8704. The client system will have a dedicated processor or microcontroller 8700. The microcontroller 8700 is more probable than a processor because of the constrained nature of most of the Internet of Things nodes. Depending on the end device needs or aims 8704, the manufacturer can include specific peripherals to the multi-role Internet of Things communication module 8703 so that it can play different roles. For example, there are communication interfaces that are external to the multi-role Internet of Things communication module 8703. For instance, LAN interfaces 3201 or mobiles interfaces 3216 are not expected to be available internally to the multi-role Internet of Things communication module. However, LoWPAN technologies 3204 or PAN technologies 3209 interfaces are expected to be available internally in the multi-role Internet of Things communication module. We refer to the LoWPAN 3204 and PAN 3209 technologies as Object-oriented communication interfaces while we refer to LAN 3201 or mobile 3216 technologies as Internet-oriented communication interfaces. Object- oriented communication interfaces are likely to be installed right on the multi-role module and Internet-oriented communication interfaces are likely to be external to the multi-role module. Following this model, the Ethernet interface 8702 or the GSM/GPRS interface 8701 are external to the multi-role Internet of Things communication module. Both interfaces are managed by the multi-role Internet of Things communication module 8703, but installed on the client system 8704. The multi-role Internet of Things communication module 8707 8708 8709 can have several object-oriented communication interfaces installed on it. For example, it can have an IEEE 802.15.4 subGHz communication interface 8706 as well as a Bluetooth low energy interface 8705 right on the module. Another example could consider near-field communication (NFC) 8711.

Object-oriented architectures

An object-oriented Internet of Things architecture considers that most of the components are integrated within the business part of the system, both in the connected object and at the server-side.

Referring to figure 3, the object-oriented Internet of Things architecture is also referred to as a proprietary way of implementing the Internet of Things. For instance, this means that the communication module 8505 is likely to act more as a network transceiver rather than as a complete toolbox for the Internet of Things. This communication module 8505 typically has a physical and medium access control layer integrated 8530 as well as a network stack 8528 to operate on the communication interface 8530. The security 8524 provided within such a module is simple and only concerns medium access control layer security. Medium access control layer security - in the case of the IEEE 802.15.4 standard - is relatively simple because it relies on symmetric cryptography with predefined secrets. Therefore, to change the network security 8524 of a deployed device, one will have to go close to the connected object and update these parameters through a device user interface 8510 such as buttons for example. As the device user interface 8510 defines new parameters for the network security 8524, the business object 8508 will have to interface 8507 using a given application programming interface 8506 with the communication module 8505 and update the parameters 8524 in the communication module 8505 in consequence. In an Internet of Things architecture, there is more than the network security, there is also the application security to implement. The security requires end-to-end consideration to be efficient and adapted to a given business and installation. The network security 8524 encompasses both the interface security and the network security at the Internet protocol level using either TCP or UDP. To deliver information towards the server, the connected object will need compliant services 8520, usually based on web standards such as HTTP REST calls or alternative protocols used in the Internet of Things. These services 8520, when based on the REST architecture, will have resources 8521 to be synchronized with the remote server. To send the information towards the remote server using the service and the resource, a common format must be used to allow both system ends to understand each other 8522 8529. The resources available on the connected object 8521 will have their counterpart 8526 in the remote server. A business logic is also integrated both in the connected object 8519 and in the remote server 8511 . The business part of the connected object will integrate the data acquisition component 8523. This component will generate the data 8523 that feeds the different resources 8521 of the system. The communication module 8505 will open a connection from the connected object 8516 towards the remote server 8513 using a network 8514. The remote server will receive messages from the connected object. These messages will carry resources that have data embedded following a specific format. The used format 8522 in these messages must follow one of the available formats in the remote server 8529. In this object-oriented Internet of Things architecture, the server part 8504 is more likely to be a proprietary server, with optional application programming interfaces 8502 to provide connected object information to third party applications 8500 8525.

Service-oriented architectures

A service-oriented Internet of Things architecture is illustrated in figure 4. In this situation, the overall management of business related data is still localized in the business part 8557 of the object and in the business application 8550 that operates beside a connected object management middleware 8553. In this situation, the Internet of Things communication module 8554 integrates now services 8571 that match the connected object management middleware 8553 services 8569. The business application 8550 communicates with the connected object management middleware 8553 through an application programming interface 8551 delivered by the connected object management middleware 8553 in the most common cases. The networking part of this architecture is more convenient for the connected object manufacturer and for integrators because common services 8571 are available to operate directly at a network level and reduce the complexity to integrate in the business part 8557 of a connected object. Aside the services that are integrated in the Internet of Things communication module, the business part 8557 of the connected object still have to integrate a lot of components. Those components are such as: the data acquisition 8581 and management 8577; the data formatting 8574; the integration within resources 8570; the application security 8567; the business logic 8565; and even some optional user interface 8563 to interact with connected object users. A major drawback of such an approach is the distribution of the security between two entities 8554 and 8557, which lead to an incoherent end-to-end security that does not fit existing security policies. On the IT infrastructure side, the connected object management middleware 8553 integrate the counterparts of the Internet of Things communication module 8554. The connected object management middleware has to integrate also other components that allows managing list of connected objects, to maintain devices authentication information, to log connection, etc. In this approach, the business application will still have to integrate many components like the management of all the data, formats, resources, etc. coming directly from the objects. Objects connected using wireless mesh network technologies have particular communication scheme and delays. Managing devices within a mesh network is not implicit and require a certain level of expertise. The interactions between the business application 8550 and the business object will be complex because of the network transaction scheme 8559 with the wireless mesh network; special considerations must be taken when developing the business application 8550.

Resources-oriented architectures

The proposed Internet of Things resource-oriented architecture is represented in figure 5. In the connected object part 8608 of the architecture, there is more components integrated into the Internet of Things communication module 8608. This reduces considerably the development time in the business part 8611 of the connected object. The business part of the connected object can then use the Internet of Things communication module's application programming interface (API) 8609 to send the data toward the IT infrastructure of the architecture using at least one network communication 8613 8606. The IT infrastructure is composed of a connected object management middleware 8603, its API 8601 and the business application 8600. The connected object management middleware 8603 interfaces with the connected objects through the network 8605. In this approach, the Internet of Things communication module 8608 also handles data management services 8619 for the business part of the connected object. This data management services proposes the persistence management of data within embedded memories as well as seamless synchronization using the embedded services 8627. The Internet of Things communication module 8608 can also feature some user interface 8607 components to ease the configuration of the embedded features like the services 8627, security 8629 and network 8631. This user interface 8607 component within the Internet of Things communication module 8608 can be for example a PAN interface like Bluetooth to connect a smartphone or tablet device. The business part 8611 of the connected object can then receive configuration parameters by the mean of this user interface 8607. These configurations can be for example the destination address 8612 used by an embedded software service 8627 to transfer a set of resources 8624 using a specified data format 8622 and set of data 8619. There is huge advantage to embed these components into the Internet of Things communication module 8608. For instance, the business part 8611 of the connected object will be easier and therefore faster to implement, with handled strong end-to-end security and network load optimizations. This also reduces the skills required to design a connected object for the manufacturer. Then, depending on how the application programming interface (API) 8609 is proposed to the manufacturer, there is even less job for the manufacturer because libraries can directly integrate the API protocol. These libraries can also integrate typical examples of interactions. On the IT infrastructure part, the connected object management middleware 8605 integrates the counterparts available in the Internet of Things communication module 8608. It delivers as well other services for the lifecycle management of the connected objects, the data persistence, potentially aggregation services, notifications, alarms, etc. Having this Internet of Things resource-oriented architecture enables an easy mirroring of information between a business application 8600 and connected objects. The business application still have to implement specific component such as the final user interface 8616, some part of the business logic, some ways to use the connected object management middleware application programming interface (API) 8601 . The business logic can also be partially integrated into the connected object management middleware 8603 by the mean of a rule engine. The connected object can also have the rule engine counterpart integrated into the firmware. In this case, the rules must be synchronized between the boundaries of the system and can provide fail-safe mechanisms as soon as the devices have to become autonomous with respect to the IT infrastructure and can take local decisions.

Homogeneous Communication Interface

Managing multiple communication interfaces in devices designed for the Internet of Things paradigm is challenging. In the Internet of Things, the vast majority of the proposed hardware use constrained microcontrollers; whose are tiny processors with some peripherals directly embedded on the die. These systems work at low frequencies with low memory resources and power efficiency objectives as well. To support the Internet of Things, early operating systems like Contiki OS with ulPv6 Internet stack or Tiny OS were created. But these systems focus on extremely low power operation optimization and cannot fully cope with the industrial Internet of Things paradigm that require performance, security and robustness. For example, the ulPv6 Internet of stack of the Contiki OS shares a single memory buffer for all the software layers from the ISO model, from the medium access control layer towards the application layer. This reduces considerably the performance of the system as well as its capacity to manage efficiently multiple communication interfaces. Another important point is about processing. Contiki OS is an event-based operating system, which is very well suited for battery operated device with single communication interface and small embedded applications. To integrate an Internet protocol with as a suite of software, implementation choices are necessary which lead to partial protocol implementation and light versions of some applications, limiting the use-cases.

Other operating systems started to appear after the awakening of these constrained operating systems such as Contiki OS or Tiny OS. These new systems - for example RIOT OS or mbed OS - target more powerful devices with extended capabilities like managing multiple communication interfaces and providing better security support and performance. Although all of these operating systems provide local intelligence to devices, they still leave important development to connected object manufacturers that want to enter in the Internet of Things arena.

In general, state-of-the-art multi-interface management in the Internet of Things follows these models:

Model A: The first model provides a local intelligence to devices with communication interfaces that are only compliant with one of the Internet protocol versions. In this context, the management of the multiple communication interfaces is delegated to the embedded Internet protocol stack.

Model B: The second model provides a local intelligence to devices with communication interfaces that are compliant with both the Internet protocol version 4 and version 6. In this model, the multiple communication interfaces management are handled by the Internet protocol stack if it supports dual version. Otherwise, a higher level application must handle the translation between IPv4 and IPv6 protocols and vice-versa.

Model C: The third model provides a local intelligence to devices with communication interfaces that are not necessarily compliant with the Internet protocol. In this model, the management of multiple communication interfaces is partitoned between the Internet protocol stack and applications. For example, the Internet protocol stack can manage Internet compliant interfaces either for a single version of the Internet protocol and delegate the rest to higher level applications, or for both version of the Internet protocol and still delegate the Internet non-compliant interface to higher level applications.

However, these existing models suffer from various limitations. Considering a local intelligence in Internet of Things devices can induce side effects while deploying in wireless mesh network with support of multiple gateways. Referring to figure 1 , let us consider the Internet of Things device 7053, which is in the center of the wireless mesh network 7054. In this wireless mesh network 7054, there are also three gateways 7052, 7055 and 7056 that connects the wireless mesh network 7054 to a native Internet network, which could be the global Internet or a private network. For the purpose of this example, we define the gateway 7052 as a GSM/GPRS gateway, the gateway 7055 with a standard wired Ethernet link, and the gateway 7056 with GSM/GPRS link again. The node 7053 is at a three-hop distance from the gateways 7052 and 7056 while being at four-hop distance from the gateway 7055. The number of hop to reach a gateway is significant for the communication latency. GSM/GPRS is a cellular technology usually managed by Internet Service Providers (ISPs) which bill their customer for the usage of the network. In a network like 7054, you will have messages that are critical for a business and other messages less important. It would be therefore interesting to use the Services Providers' routes for the critical messages and the longer routes free of charge for the less important messages. Intelligent routing based on economic constraints and predefined qualities of service is therefore a desirable feature of the Industrial Internet of Things devices.

Multi-application support for wireless mesh network

We focus here in the Internet of Things made of connected devices that embed active electronic systems. A major drawback in current Internet of Things applications is that they use dedicated network for a single application, which make silo applications that are unable to communicate with other applications without the mean of a central management system and specific application programming interfaces. In the context of a smart city, having the possibility to reuse an existing network to support other applications in the future is a strong argument to accelerate the deployment of an Internet of Things communication infrastructure. We focus her also in wireless mesh network technologies only.

In the context of a smart city, the smart lighting application is one of the perfect use- case to build an Internet of Things communication infrastructure that covers the entire city area. Traditional wireless mesh networks use a single gateway to reach the Internet network. This single gateway represents a single point of failure in the system. More recently, it has been possible to design wireless mesh network with multiple gateways to reduce the weaknesses of the network concerning Internet connectivity. To support multiple gateways, one needs a powerful routing algorithm able to discover and manage multiple gateways as well as the ability to communicate from peer to peer without the need to reach the root of the network.

Disseminated gateways in a mesh network may have different Internet connectivity available; for example, one gateway can have a GSM/GPRS communication interface while another gateway can have a standard wired Ethernet communication interface. At a city scale, this heterogeneity of Internet connectivity at different network nodes has a direct impact on both the quality of service and the overall infrastructure costs.

In general, state-of-the-art multi-application wireless mesh networks follow these models: Model I) in this first model, the wireless mesh network uses a simple Carrier Sense Multiple Access Channel Assessment (CSMA/CA) method. This method checks the carrier to know if it is currently idle or not. If the medium is not idle, this means that another device is currently communicating. At that time, the device that wants to communicate will wait some time and assess the channel again until it can transmit or until a maximum number of tries is reached. If the device cannot transmit because the medium was busy at each try, then a network error has to be triggered to the higher software layer that initiated the communication. Using this medium access control layer scheme to access the channel, the devices form a huge and shared network. It is impossible then to regulate how devices use the shared medium and may lead to network instability and long response time when timing are critical.

Model II) in this second model, the wireless mesh network uses time division multiple access (TDMA) scheme. This scheme is based on a so-called superframe, which is a temporal structure, which drives when devices communicate. The network coordinator manages the superframe. Following the IEEE 802.15.4 specification, it could be only one coordinator per network. Wireless mesh network are low-rate networks with throughputs between 1 kilobit per second to several tens of kilobit per second. The deepest a wireless mesh network is, the longer the superframe is. Designing multi- application networks with TDMA will then affect the application latency a lot because of the length of the superframe. Referring to figure 12, a superframe is made of an active period 8354 and an inactive period 8359. The superframe is delimited by a beacon 8350, which describes how the superframe is built. The inactive period 8359 is used for other devices to propagate the active period of the superframe. The active period 8354 is further divided into two parts: the contention access period (CAP) 8353 and the contention free period (CFP) 8357. The content access period is a period during which devices compete to access the channel using a standard CSMA/CA scheme. According to the IEEE 802.15.4 standard, the TDMA medium access scheme divides the active period 8354 in 16 time slots like 8351 and 8352. The slots in the contention access period are merged together to form a single logical slot in which devices can communicate without any control on the quality of service. Devices can require the coordinator to allocate specific slots to them. These reserved slots are called guaranteed time slots (GTS) such as 8358. The opening beacon 8350 of the superframe indicates to nodes, which one is allowed to communicate in a guaranteed time slot. Having allocated time slots allows nodes to have a dedicated bandwidth. The contention free period 8357 is a period that depends on how much guaranteed time slots are allocated. A device may reserve multiple adjacent guaranteed time slots to have a longer time at disposal for communicating. For example, a device can reserve the guaranteed time slots from slot 8356 to slot 8358. In a TDMA system, the superframe occurs periodically. The period between two superframes is called the beacon interval (Bl) 8362. Referring to figure 13, the contention free period 8154 is composed of two guaranteed time slots 8153 and 8155. The inactive period 8156 of a superframe also allows devices to save energy by entering into a sleeping mode and schedule their wake-up following the superframe description in the beacon 8150. Referring to figure 14, a superframe with an inactive period 8202 longer than the active period 8201 allows one of its neighboring nodes to forward the original active period 8208 to nodes one hop far. The original active period 8201 of the network superframe starts by the beacon 8200, which describes the structure of the superframe. This transmitted active period 8201 is received 8206 by the nodes that are one-hop distant from the coordinator device. Once the inactive portion of the original device starts 8202, the one-hop distant node can start transmitting the active period 8208 again to propagate the TDMA network. The original device - the coordinator - will ignore that repeated active period 8208. The remaining time 8209 between the end of a repeated active period 8208 and the start of a new superframe beacon 8210 should be calibrated to be as small as possible so that the network is more efficient.

SUMMARY OF THE INVENTION

In a first aspect the invention provides a common core electronic multi-role module configured to be soldered on a client electronic system, which is part of the Internet of Things, the module having applications and a networking stack installed on it, the module further being configured to adapt its role depending on an availability of a specific communication interface, the module being configured to connect the client electronic system to a network. The module comprises at least a processor for constrained device; an interface towards the client electronic system; a provided application programming interface intended for the client electronic system; and at least one communication interface configured to interface the core electronic multi-role module with an intended network communication device. The processor for constrained device is a microcontroller. The processor executes at least one embedded application. The processor of the core electronic multi-role module has a networking stack to manage the at least one communication interface. The processor of the core electronic multi-role module runs asymmetric cryptography security primitives to operate as a gateway. The at least one embedded application has specific optimizations and shares resources in that sense for hardware of the core electronic multi-role module.

In a second aspect, the invention provides a single multi-role module architecture for a device which is part of the Internet of Things, the device having a variable list of resources available to the device, a client processor that handles business activities of the device, the architecture being intended to connect the device with at least one network with the aim of using one of the device's resource in line with a determined quality of service parameter associated to this one resource. The architecture comprises at least an electronic module; at least one communication interface configured to interface the electronic module with an intended network communication device; and a business module designed to interface the electronic module with the client processor. The electronic module comprises a microcontroller, the at least one communication interface, and an embedded memory storing for each resource an associated history of values, and associated quality of service parameters. The microcontroller comprises a homogeneous communication interface configured to manage the at least one communication interface to communicate with any one of the at least one network, thereby being configured to select for the one of the device's resource the associated quality of service and to select the one of the at least one network corresponding to the selected quality of service.

In a third aspect the invention provides a method for initializing a single multi-role module integrated in a business module. The method comprises steps of initializing the business module; initializing from the business module the single multi-role module system and network interfaces with specific parameters using the interface between the client processor and the electronic module; and configuring from a client processor on the business module, single multi-role module's self-defined resources and applications using an interface between the client processor and the electronic module.

In a fourth aspect, the invention provides a method for registering a resource value in an electronic module from a client processor in a business module. The method comprises steps of allocating a business module state of the business module as a resource in the electronic module using an interface between the client processor and the electronic module and assigning a quality of service; configuring applications embedded in the electronic module using the interface between the client processor and the electronic module to synchronize the allocated resource with a server; feeding with business values from the business module the resource in the electronic module using the interface between the client processor and the electronic module to let configured applications to synchronize them on a remote server; and getting feedback from the electronic module that the resource's value registration about the operation result.

In a fifth aspect, the invention provides a Homogeneous Communication Interface (HCI) comprising at least: an interface agent (IA); a routing agent (RA); and an Homogeneous Communication Interface Application Programmer Interface.

In a preferred embodiment of the Homogeneous Communication Interface (HCI), the Interface Agent (IA) is configured to manage both Internet compliant interfaces and Internet not-compliant interfaces.

In a further preferred embodiment of the Homogeneous Communication Interface (HCI), the Interface Agent (IA) is configured to manage separately cellular technologies, local area network LAN technologies, personal area network PAN technologies and low-rate wireless network.

In a further preferred embodiment of the Homogeneous Communication Interface (HCI), this is configured to make use of specific quality of service per connection. A quality of service in the HCI indicates that the lowest latency in the wireless mesh network is preferred for that connection. A quality of service in the HCI indicates that the fastest delivery in the wireless mesh network is preferred for that connection, the fastest delivery being a compromise of the best probability of successful delivery and the lowest latency. A quality of service in the HCI indicates that the shortest path in the wireless mesh network is preferred for that connection. Furthermore, or alternatively a quality of service in the HCI indicates that the safer delivery in the wireless mesh network is preferred for that connection, the safer delivery being the path with the best probability of successful delivery.

In a further preferred embodiment, the Homogeneous Communication Interface (HCI) is configured to manage specific constraints per connection within a wireless mesh network. A first specific constraint limits the maximum number of hops being crossed by a connection in the wireless mesh network. A second specific constraint indicates that a costly cellular-based technology is forbidden for that connection. A third specific constraint indicates that a minimum successful probability of delivery within the wireless mesh network for that connection must be respected. A fourth specific constraint indicates that a maximum latency for the connection within the wireless mesh network must be respected.

In a sixth aspect, the invention provides a multi-application network architecture for Internet of Things wireless mesh networks, for which an application is identified by at least one functionality being implemented on at least one Internet of Things device, each application having furthermore a specific quality of service assigned. The multi- application network architecture comprises at least at least two Internet of Things devices; at least one application being executed on each of the at least two Internet of Things devices. The Internet of Things devices share the same wireless communication technology and can communicate between pairs. The at least one application has a specific quality of service assigned. Each of the at least two Internet of Things devices prioritizes communication in the multi-application network by sorting pending packets according to the specific quality of service assigned to the respective at least one application being executed. Pending packets that are postponed for more important packets to transmit, are transmitted after a given number of postpones.

In a further preferred embodiment, the multi-application network architecture further comprises a central management system, which is configured to provide a central management that lists the applications executed on the Internet of Things devices, that assigns the quality of services the applications.

In a further preferred embodiment, the multi-application network architecture further comprises a central managing system, which is configured to define the list of applications allowed to operate in the network.

In a further preferred embodiment, the single multi-role module architecture further comprises an index of resources integrated into the common core electronic multi-role module easing the management of data for both common core electronic multi-role module needs and motherboard hosting the common core electronic multi-role module needs.

In a further preferred embodiment, the single multi-role module architecture further comprises a central management system including server counter-part of the embedded index of resources integrated within the common core electronic multi-role module easing the synchronization between an object connected using the common core electronic multi-role module and a remote server.

In a seventh aspect, the invention provides a method for securing reduced function devices in a wireless mesh network that limit the amount of traffic for the management of security in the network system, the method making use of a mobile programming device for the commissioning of the devices, whereby the mobile programming device may be a smartphone or a tablet. The method comprises steps of getting a digital identity of a reduced function device we want to connect to the wireless mesh network through a full function device already acting as a router in that wireless mesh network; connecting a mobile programming device to the full function device on which the reduced function device will try to connect to; provisioning a new security code on the full function device associated with the digital identity of the reduced function device; getting the security code provisioned on the full function device to the mobile programming device; connecting the mobile programming device to the reduced function device we want to connect to the wireless mesh network; transferring the security code coming from the full function device into the reduced function device via the mobile programming device; saving the configuration in the reduced function device; initiating a connection from the reduced function device to the full function device being part of the wireless mesh network; the full function device being already aware of the reduced function device as well as the security code to apply on the transmission; and the full function device decrypting messages from the reduced function device and encrypting them using the securities of the wireless mesh network.

In a further preferred embodiment the method for securing reduced function devices in a wireless mesh network further comprises steps of connecting a central management system from the mobile programming device; saving the reduced function device digital identity into the central management system as a device being part of the wireless mesh network; signing the reduced function device digital identity with the central management system own digital identity; sending back the signed reduced function device digital identity to the reduced function device via the mobile programming device; and associating in the central management system the reduced function device to the full function device the reduced function device will connected to.

In a further preferred embodiment the method for securing reduced function devices in a wireless mesh network further comprises steps of connecting the full function device on which the reduced function device is attempting a connection with the configuration made via the mobile programming device to the central management system; checking the reduced function device on the central management system by the full function device upon association request; this check comprising either a validation of the reduced function device digital identity signed by the central management system own digital identity; or a validation of the reduced function device digital identity not signed by the central management system own digital identity by requesting the central management system about the reduced function device digital identity validity, the method further comprises responding the reduced function device with the association response via the full function device.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 describes a typical wireless mesh network with multiple gateways. The wireless mesh network is composed of full function devices able to route any packets within the network.

Figure 2 describes different integration of object-oriented communication interfaces within the common core electronic multi-role module for the Internet of Things.

Figure 3 describes a standard object-oriented Internet of Things architecture. In this approach, most of the logic is integrated in the business part of the connected object and in the business part of the server.

Figure 4 describes a standard service-oriented Internet of Things architecture, where the logic for network is almost entirely integrated within the communication module of the connected object and in the server part; and the business logic is still entirely located outside the communication part.

Figure 5 describes a resource-oriented Internet of Things architecture, where part of the business logic is also integrated within the communication module for the Internet of Things, such as the client/server applications, data management, persistence, time synchronization services, etc.

Figure 6 describes a general architecture for the Internet of Things application, including gateways, Internet of Things nodes, networks and an IT infrastructure Figure 7 describes the positioning of the common core electronic multi-role module with respect to other common communication devices.

Figure 8 describes the integration of the common core electronic multi-role module within a typical Internet of Things situation.

Figure 9 describes the arrangement of communication technologies as seen by the common core electronic multi-role module.

Figure 10 describes the differentiation between Internet-oriented and object-oriented communication technologies and how they are integrated physically in an end-device.

Figure 1 1 describes the problematic of managing multiple communication interfaces for user applications.

Figure 12 describes a typical time division multiple access TDMA superframe structure.

Figure 13 describes how the guaranteed time slots of TDMA are integrated within the superframe structure.

Figure 14 describes how a TDMA network becomes multi-hop compliant in its simplest case.

Figure 15 describes how TDMA guaranteed time slots can be now assigned to applications rather than specific nodes.

Figure 16 describes how the TDMA network operates over 2-hop networks.

Figure 17 describes the issues of TDMA based multi-gateways network about synchronization.

Figure 18 describes the implemented Internet of Things stack within the common core electronic multi-role module.

Figure 19 describes the components being used for firmware update over-the-air in the common core electronic multi-role module.

Figure 20 describes how the resources are managed by the resources index and persisted within an embedded memory.

Figure 21 describes how the intelligence is distributed with the homogeneous communication interface between devices in the network as well as the different qualities of services applied in the wireless mesh network to enhance performance and robustness.

Figure 22 describes how security can be extended to leaf-node device in a lighter way than the security used for the wireless mesh network full function devices.

Figure 23 describes a complex situation with multiple gateways and Internet-oriented communication technologies for a node in the center of the wireless mesh network.

Figure 24 describes a typical use-case of an Internet of Things backbone wireless mesh network over a city with streetlights and gateways as well as reduced function devices below the streetlight connecting them in a star topology.

Figure 25 describes in an architectural way the use-case of figure 24.

Figure 26 describes in-depth the homogeneous communication interface components and interactions. DETAILED DESCRIPTION OF THE INVENTION

Universal Internet of Things Communication Module

Resource-oriented architecture Resume

The proposed universal Internet of Things communication module - or multi-role Internet of Things communication module - is based on the previously described resource-oriented Internet of Things architecture. It includes components that ease and accelerate the development of a new connected object. The network synchronization of values, data, resources with specific formats through application services relieve the manufacturer of the connected object from tremendous developments. In short, the resource-oriented Internet of Things architecture suppose that an Internet of Things communication module delivers tools for a manufacturer to save data, to manage an history, to synchronize data to a remote server, to format the data, to secure the communication, etc.

Multi-role ability of the module

Preferably, the multi-role Internet of Things communication module is able to manage multiple communication interfaces. For instance, an Internet of Things communication module can still be multi-role if it has a single communication interface that is a wireless mesh network interface. Indeed, in the wireless mesh network, it could be a various set of role proposed and supported like network coordinator, reduced function devices or full function devices. A network coordinator in the IEEE 802.15.4 philosophy is the network manager; it generates the wireless mesh network and handles association, disassociation and security management for the network. A reduced function device only communicates for its own purpose, it does not care about others Internet of Things communication module communications. A full function device will handle both its own network traffic and the network traffic coming from other node in such a way that a mesh network can appear.

Integration of the module within a business or client board

Preferably, the common core electronic multi-role module - or multi-role Internet of Things communication module - is to solder on a motherboard. The motherboard is expected to contain the business components of the object being connected with the common core electronic multi-role module. The motherboard will feature a dedicated controller, either a processor or a microcontroller, that interfaces the common core electronic multi-role module with a standard system interface as for example a universal asynchronous receiver transmitter (UART) interface. The motherboard controller will control the common core electronic multi-role module using a given application programming interface.

Preferably, the common core electronic multi-role module uses the Javascript object notation (JSON) format in the control interface between the motherboard's controller and the common core electronic multi-role module. This enables the business module developer to easily define the configuration sequence in a human-readable fashion. These JSON payloads are then carried using the framing protocol of the interface between the motherboard controller and the common core electronic multi-role module. Supported interface categories

Preferably, the multi-role Internet of Things communication module handles four types of communication technologies. The first type handled by the multi-role Internet of Things communication module is about local area network technologies like IEEE 802.3 Ethernet, IEEE 802.1 1 Wi-Fi, fiber or even power line communication (PLC). The second type of communication technologies handled by the multi-role loT communication module is the cellular-based communication technologies. Among the cellular technologies, there is the GSM/GPRS, 3G/4G technologies as well as the more recent Internet of Things compliant cellular technologies provided by SigFox or Semtech LoRa® for instance. The third type of communication technologies is based upon Internet of Things RF technologies, which use LoWPAN interfaces together with IEEE 802.15.4 access technologies allowing to connect objects in a range of several tens of meters to one to three kilometers. The fourth type of communication technologies are dedicated to human-to-machine interactions at short ranges such as Bluetooth Smart, NFC or RFID technology.

Grouping of object and internet communication interfaces

Preferably, the multi-role Internet of Things communication module differentiates two category of communication technologies. The first category concerns Internet-oriented communication technologies while the second category considers object-oriented communication technologies. The idea behind the Internet-oriented versus the object- oriented is simple: Internet-oriented technologies targets the interconnection of object- oriented technologies with the native Internet. Object-oriented technologies focus on connected object interconnectivity as well as interaction with human for all the lifecycle operations.

Interfaces eligible to be installed into the communication module and interfaces that are deported.

The proposed single multi-role industrial Internet of Things module architecture and common core electronic multi-role Internet of Things module follows the same concept, which supposes that object-oriented communication technologies are candidates to be integrated right onto the Internet of Things communication module while Internet-oriented communication technologies are more likely to be integrated on the daughterboard on which the Internet of things communication module is going to be soldered.

Preferably, the multi-role Internet of Things communication module integrates at least one LoWPAN type of communication interface and at least one personal area network communication interface. In this way, a connected object can benefit from a wireless mesh network infrastructure and interactions with humans through smartphones or tablets. This will ease the commissioning of devices as well as the entire operations during the object lifecycle.

Homogeneous Communication Interface

The Homogeneous Communication Interface (HCI) allows higher-layer applications to communicate seamlessly and optimally on multiple communication interfaces. The HCI integrates a logic to manage these different interfaces according to the categorization proposed in the figure 9. Communication Interfaces

Preferably and referring to the figure 9, the multi-role Internet of Things communication module 3202 manages multiple kinds of communication interfaces. The managed communication interface types are local area network (LAN) Interfaces 3201 ; Mobile interfaces 3216; personal area network (PAN) interfaces 3209; and low power wireless personal area network (LoWPAN) Interfaces 3204. The LAN interfaces are for example IEEE 802.3 Ethernet technology 3207, IEEE 802.1 1 W-Fi 3210 or P1901 powerline communication 3200. These interfaces have free and unlimited Internet connectivity available. Then, there are the mobile interfaces, which are also referred to as cellular wireless technology. These mobile interfaces 3216 include standard 2G GSM/GPRS 3212 technology, 3G or even 4G technologies 3214. The awakening technologies more recently developed by SigFox company and LoRa® by Semtech company are fitting this category of interfaces. Cellular technologies are most of the time managed by internet service providers (ISPs) which bill their customers for the network usage. The PAN technology category 3209 encompasses technologies like radiofrequency identification (RFID) 3217, near-field communication (NFC) 3218, Bluetooth 3215, Bluetooth low energy (BLE) 3213 and ANT 3211. These technologies are star topology oriented with the ability to interface with smartphones or tablets. Finally, the LoWPAN interfaces 3204 are the foundation of the Internet of Things active connected object paradigm. These technologies 3204 are used to develop wireless mesh networks for example. Among the available LoWPAN technologies, there are the IEEE 802.15.4 compliant radio technologies, the ZigBee® 3203 and the Z-Wave 3205 technologies. LoWPAN technologies are no more limited to personal area network as its name tends to suggest. As wireless mesh network can reach tens of kilometers, the network range is tremendously higher than the personal area.

Application Programming Interface

Referring to figure 26, the homogeneous communication interface (HCI) integrates an application programming interface (API) 5103. This HCI API 5103 hides the complexity of the multiple communication interface manager to upper layer applications. This will simplify considerably the upper layer applications about their networking activities they could have.

Preferably and referring to figure 26, the homogeneous communication interface (HCI) application programming interface (API) 5103 enables the introduction of added-value parameters to be defined by application at function's call. These added-value parameters allows the application to define, during a network transaction or during the exchange of individual messages some quality of service information that will drive how the homogeneous communication interface will deal with the connectivity available in the network.

Interface Agent

Preferably and referring to figure 26, the homogeneous communication interface (HCI) includes an interface agent 5105. The interface agent is responsible for managing the available communication interface on the device. Referring to the figures 9 and 26, the homogeneous communication interface manages four kind of communication interfaces: the local area network LAN communication interfaces 3201 5112; the mobile communication interfaces 3216 5108; the personal area network PAN communication interfaces 3209 5109; and the LoWPAN interfaces 3204 5115. Preferably and referring to figure 26, the homogeneous communication interface (HCI) interface agent 5105 count the incoming and outgoing traffic for each managed interface so that activity can be tracked in live by the system. Depending on specific security policies within the device, this system can trigger alerts for unexpected use of specific communication interface.

Preferably, the homogeneous communication interface (HCI) interface agent manages hot-plug of communication interfaces. For example, plugging an Ethernet cable into the compliant connector can set the Ethernet interface up and vice versa.

Preferably and referring to figure 26, the homogeneous communication interface (HCI) PAN communication interfaces 5109 are managed differently than the other communication interfaces 5107. For instance, the personal area network technologies are well suited for parameter/value tuple to be exchanged. This means that these technologies are adapted to the product lifecycle management, typically the provisioning, the configuration, maintenance operations, etc.

Preferably, a single communication interface Internet of Things communication module using a wireless mesh network is expected to focus on the gateways within this mesh network. In such a case, the homogeneous communication interface (HCI) will bridge the quality of service defined with network transaction downward to the medium access control layer to regulate the routing algorithm. This regulation will make the routing algorithm to consider more one or the other of the network metrics associated with the quality of service defined for that network transaction.

Distributed intelligence

Preferably, the homogeneous communication interface (HCI) qualities of service that application can define for network transactions or individual message have a scope global to the wireless mesh network. This means that qualities of service are shared by all the devices within the wireless mesh network. This is particularly interesting in a wireless mesh network with the support of multiple gateways. A wireless mesh network with a single gateway is improved by this functionality. The concept is to know in the Internet of things node which Internet oriented communication interface is available in the network gateways. With such information distributed in the wireless mesh network to the nodes, then they can take the decision to use one or the other of the gateways to reach the Internet by complying with the specified qualities of service defined through the homogeneous communication interface calls.

Preferably, the Internet of Things nodes search for the available gateways in the network. Once these gateways has been discovered, then the Internet of Things node can try a connection to them to retrieve their available communication interfaces and associated constraints. For instance, one gateway could have a free-of-charge Ethernet access while another gateway can have a costly GSM/GPRS connection. If a message has a low quality of service associated, then the homogeneous communication interface can decide to use the maybe longer way with the Ethernet connectivity, and save money by avoiding the transmission on the GSM/GPRS gateway. In addition, if a very important message must be transmitted out of the network towards a remote server and if a gateway with a costly GSM/GPRS communication interface is better suited for this kind of traffic, then the homogeneous communication interface can choose to take the costly route for complying with the associated quality of service. Routing Agent

Referring to figure 26, the homogeneous communication interface (HCI) includes a routing agent 5100. The routing agent is responsible for defining which communication interface the network transaction should take. The decision is made using the input quality of service parameters or constraints as well as the local state of the device or the state of network's gateways.

Preferably, the homogeneous communication interface (HCI) manages the transport layer of the device for applications. Typically, it is up to the homogeneous communication interface to open sockets for applications. Depending on the application, a TCP or UDP socket will be used. The definition of the type of transport layer the network transaction must follow is defined in the application programming interface call.

Preferably, the homogeneous communication interface (HCI) monitors how routes are used throughout the network so that this kind of information can also influence the selection of one route or the other during the decision process. For instance, by monitoring the most used route in the system enables the homogeneous communication interface (HCI) to set that most used route as default route in the system.

Business-metric oriented routing

Preferably, the homogeneous communication interface (HCI) supports different quality of service associated with network transactions. These qualities of service are used by applications or attached to resources managed by the resources index. The resources index is a component within the common core electronic multi-role module for the Internet of Things. A resource is a container for values being either string formatted or numeric. A resource is described with some meta-data. The homogeneous communication interface (HCI) uses the shared state of gateways to decide which gateway is best suited for a network transaction. This decision uses the available Internet-oriented communication interface for each gateways as well as the distance they are from the node taking the decision. This feature is specific to the wireless mesh network. It is possible for an application or a resource to have a specific quality of service assigned. These qualities of service considers the availability of LAN or cellular communication technologies attached to a gateway, the most important metrics in the wireless mesh network are the expected transmission count (ETX) and the latency. The node willing to communication with the Internet through a gateway with some of its traffic being very important, it will maybe prefer the path with the higher expected transmission count value (higher probability of transmission) rather than the best latency with a poor probability of successful transmission.

Preferably, the homogeneous communication interface (HCI) limits the decision of picking a gateway for a given network transaction using constraints. The constraints are defined along with the qualities of service for either the applications or the resources. For instance, an application can specifically require to not use cellular communication interfaces in the wireless mesh network to communicate. It can also define that if there is no other kind of communication, the cellular interface that are available can be used anyway. These constraints can define which interfaces are authorized and which other interfaces one cannot use. The constraints can also define that if multiple gateways are in competition for a selection, then the difference between the two in number of hop counts can restrict the selection to the close one rather than the farest one.

Preferably, when a common core electronic multi-role module connects a wireless mesh network, it should discover the available gateways once associated, without waiting for an application communication to occur. Once the gateways are discovered, then the homogeneous communication interface can ask the discovered gateways about their available user interfaces. In this way, the device is quickly up and running.

Preferably, when a common core electronic multi-role module connects a wireless mesh network, the association process is forwarded by intermediary nodes toward a gateway, which in turn will forward the association requests toward a central management system on the Internet.

Preferably, when a common core electronic multi-role module connects a wireless mesh network, it can receive a list of the available gateways if the association request is accepted by the system. The system being a gateway or a central management system. This allows the system to have fewer packets traveling in the wireless mesh network. This will make the connecting node aware of the available gateways, but it still does not know who they are in the wireless mesh network. However, this avoid the nodes to automatically generate the broadcast of routing requests. They can use unicast requests towards these gateways or a selection of these gateways.

Preferably, gateways within a wireless mesh network running the homogeneous communication interface will flood periodically status information about their Internet- oriented interface and their load, that load being a network load, a processing load, or/and a memory load. The network load is determined using the medium access control layer scheme and its allowed duty cycle. For instance, if the MAC scheme allows for 10% of transmission in the wireless band and we use half of this transmission, then the instantaneous load is about 50%. It is very important to prevent the network to be unstable by sending periodic status information without some regulation control. The instantaneous network load is given for a specific period in which the medium access control layer guarantees that there are no more transmission than allowed by the standard. For example, this period can be up to one hour for the IEEE 802.15.4 European bands. The implemented MAC scheme can pick 30 seconds, 1 minute or any value up to this one-hour maximum for this example.

Preferably, the common core electronic multi-role module for the Internet of Things computes the network load by smoothing instantaneous computed load. The smoothing of the instantaneous computed network load is done using a pass-band filter on a history of instantaneous computed load.

Preferably, when a common core electronic multi-role module connects a wireless mesh network, the intermediary node on which the common core electronic multi-role module attempts the connection, should monitor and filter the traffic coming from that node to protect the wireless mesh network from triggered actions by repeated association requests.

As an example and referring to the figure 23, the homogeneous communication interface (HCI) of the node 8903 will have to choose among the five available gateways 8900, 8908, 8909, 8913 and 8914 in the wireless mesh network. Consider that the gateways 8900, 8908 and 8909 have a cellular communication technology, is costly and often limited in bandwidth. Then consider that the two leaving gateways 8913 and 8914 are connected using a free-of-charge LAN communication technology like Ethernet. The node 8903 needs to communicate with the Internet for one of its embedded applications. It will ask a route towards the destination located in the Internet. This route request will flood the network to reach the available gateways and connected networks. All the routers having the ability to reach that destination will respond to the originator node 8903. The route from the node 8903 towards the GSM/GPRS gateway 8900 is going through two intermediary nodes that are 8902 and 8901. The route from the node 8903 toward the GSM/GPRS gateway 8908 is going also through two intermediary nodes that are 8904 and 8907. For the last GSM/GPRS gateway 8909, this is a similar situation with respect to that of nodes 8905 and 8906. This makes these three GSM/GPRS 8900, 8908 and 8909 in competition about the hop count metric. The node 8903 therefore has to consider other metrics to get the most appropriate gateway among these three if the network transaction is willing to authorize and use these technologies. For instance, the most common metrics used to differentiate routes in wireless mesh networks are the expected transmission count (ETX), which is the successful probability of transmission, or the latency among the other received signal strength indicator (RSSI) and link-quality indicator (LQI). Typically, for an alert message generating by the node 8903 towards a destination in the Internet, the node 8903 may pick the gateway with the best compromise between ETX and the latency in such a way that it has the fastest route with the higher probability of transmission, i.e. the safer one. If the message being sent by the node 8903 is not as important as alert messages for example, then it can take another route and balance the load in the network. For instance, the path to the gateway 8913 and 8914 that provides free-of-charge Ethernet connectivity is longer than the path toward the GSM/GPRS gateways 8908, 8900 and 8909. The number of hops is an interesting metric, but other metrics like a RSSI, LQI, ETX or latency are more valuable. Typically, the ETX and latencies metrics include in some ways the RSSI and LQI metrics.

Preferably, the homogeneous communication interface (HCI) manages predefined qualities of services using the wireless mesh network gateway shared states and wireless mesh routes toward these gateways. A quality of service can define a route with the best ETX metric. Another quality of service can define a route with the best latency. Another quality of service can normalize and merge both ETX and Latency metric to have the best of both.

Multi-Application Network

A wireless mesh network based on the IEEE 802.15.4 specification, for example, can use time division multiple access (TDMA) medium access scheme, or the carrier sense multiple access channel assessment (CSMA/CA). A wireless mesh network can also use different medium access scheme.

The multi-application ability of a wireless mesh network is strongly linked to the medium access control scheme in use. The performance of the multi-application wireless mesh network will be also strongly affected depending on the medium access control scheme in use.

TDMA Based

Referring to figure 16, time division multiple access (TDMA), based multi-application wireless mesh networks require long inactive period 8311 in the superframe structure announced in the beacon 8302 to carry the mesh network. A transmitted beacon 8302 and active period 8305 from the coordinator 8300 will be received by a neighboring node of that coordinator 8301. This received active period 8304 of a coordinator neighboring node 8301 could not been also received by a node a 2-hop distance from the coordinator because of radio range. This is exactly why the inactive period 8311 of the superframe structure must be long enough to allow intermediary nodes like 8301 to forward a superframe generated by a network coordinator 8300 to distant nodes like 8316. During the inactive period of the coordinator 8311 , a neighboring node at 1 - hop distance of the coordinator like 8301 can forward the active period of the superframe to node at 2-hop distance from the coordinator 8300 like node 8316. That repeated active period 8308 will be ignored by the coordinator 8300 because it has been received during its inactive period 8311. Finally, the 2-hop distant node 8316 from the network coordinator 8300 will be able to forward again that superframe 8321 to reach 3-hop nodes. When the active portion of the superframe 8321 is transmitted again by the 2-hop nodes 8301 , the network coordinator 8300 does not hear it good enough to understand it. The optimal case for these TDMA wireless mesh networks start to appear at the 2-hop distant indicating the network coordinator can transmit a new superframe without affecting the flooding of the previous one. Actually, this is working in a very specific topology: the tree mesh topology. This topology assumes that the mesh network is physically not performing communication loop.

Referring to figure 17, the TDMA network coordinator is located at node 8351. The network coordinator device 8351 generates the TDMA superframe and distributes the superframe to its neighboring nodes as for example 8352. Then the neighboring node 8352 can forward that superframe to its own neighboring nodes like 8353 that are away of the network coordinator in terms of radio range. In the network 8350 presented in this figure, nodes have only a single way to reach their neighbors. The mesh network has a very weak link redundancy with adjacent nodes, which makes the TDMA medium access scheme to get the best performances. Considering now the second network 8355 of this figure, a routing loop is now placed in the network, which induces synchronization issues with the superframe dissemination. At that particular point in the network, the devices will have perturbation in the radio reception, leading to wrong receptions and lost transmissions. These interferences lower the performance of the network and this with some repeatability. The third and last network 8358 of this figure describes a typical TDMA based multi-gateway wireless mesh network. In such a network, the multi-gateway capabilities - represented by the gateway 8359 and the gateway 8365 - is delegated to the network layer and the mesh routing algorithm. For instance, the medium access layer can have only one network coordinator that generates the TDMA superframe for the entire network. At the medium access control layer, there is only one coordinator while at the mesh routing level, in the Internet protocol adaptation layer, there is two routing devices that can handle Internet traffic natively. Therefore, at the mesh routing level, the devices that form the wireless mesh network will be able to reach the global Internet by the mean of one of these gateways. However, the second gateway 8365 has a major drawback due to the TDMA scheme managed and maintained by the first gateway 8359, which is also the network coordinator.

Preferably and referring now to figure 15, a multi-application TDMA wireless mesh network would typically use guaranteed time slots 8253 or 8255 in the contention free period (CFP) 8254 dedicated to applications rather than nodes. For example, a multi- application wireless mesh network in the context of a smart city could dedicate guaranteed time slots to smart lighting application 8253 as well as time slots smart meter application 8255. Preferably and to be efficient, this multi-application TDMA wireless mesh network should be used in depth limited mesh network to 2-hop at maximum. The shorter the mesh network is, the more performant it will be. By limiting the size of the TDMA mesh network, we ensure that the application latency is kept low because the superframe length will be shorter and happen more frequently.

TDMA wireless mesh network have also limited performance in multi-gateway wireless mesh networks. The multi-gateway wireless network will not be able to act at a medium access layer due to synchronization issues with the original network coordinator.

CSMA Based

To outdo these limitations in gateway redundancy and keep the wireless mesh network as fast as possible, the present invention proposes to use a CSMA/CA based wireless mesh network in which the multi-application capability resides directly in the adaptation layer of Internet Protocol for the medium access layer of the wireless mesh network. Managing a multi-application wireless mesh network correctly is simplified by using a central management system in support. This central management system can give, at a glance, which applications are operating on the multi-application wireless mesh network. To get this management information, the adaptation layer integrates monitoring services that synchronize the device multi-application state with the central management system.

Implementation of the MoT Stack as proposed in this invention

The proposed and preferred Internet of Things (loT) stack to support a variety of Internet of Things application and ecosystem of devices is illustrated in figure 18. There is vertically and horizontally stacked layer that composes this loT stack. Starting from the physical layer 8447, the proposed loT stack uses a so-called PHY management layer 8447 that allows the loT interface to support multiple physical layers as for example a 868MHz interface 8453, or the 2.4GHz interface 8456. These multiple PHY layers can operate in parallel under the same upper layer as well. This feature enables the system to separate physical channels from each other if the carrier support them. Interactions 8448 8451 8454 with a physical layer like 8450, 8453 or 8456 is going through the PHY management layer 8447 so that communication with the one or the other of these physical layers is seamless for higher layer software. Then comes the medium access control layer, which is also managed by a so-called MAC management layer 8437. This MAC management layer 8437 also homogenizes the operations of higher software layers and their impacts on a physical interface. Multiple medium access scheme can be supported by the MAC management layer 8437. The selection of the medium access scheme in use can be also dynamically picked among the list of available schemes. Example supported MAC schemes are carrier sense multiple access with channel assessment (CSMA/CA) scheme 8441 , or the time division multiple access (TDMA) scheme 8443. Some common features of schemes are integrated into the management layer 8437 as well. This prevents code duplication and accelerates the development time of new schemes by reusing proven software components.

Briefly, the CSMA/CA access scheme is a listen before talk medium access scheme, which start by assessing the radio channel to check if another device is already using the medium. If the medium is idle, then the device can start to communicate, otherwise, the device will pick a windowed random number that will drive a waiting time during which the device will have to wait before trying to access the channel again. This random number lowers the issues of synchronous requests between devices and increases the probability of accessing the channel for any device in the network. There is also a maximum number of tries of channel access, which, if exceeded, will raise a network error within the device. In that particular access error case, the system may also trigger network messages to inform nodes about a broken radio link towards a specific device. It is up to the routing algorithm to manage these kinds of errors.

Briefly again, the TDMA scheme is a way to control over the time how a device accesses the channel. For instance, the timing structure that rules the device medium accesses is generated by a network coordinator. This structure is composed of an active period and an inactive period. The active period is further sub-divided into two parts, the contention access period (CAP) and the contention free period (CFP). The inactive part allows the devices to sleep and save energy as well as extending the network by repeating active period during originator inactive periods. The active period is sliced into time slots that can be reserved by specific devices. Those reserved time slots are called guaranteed time slots and they compose the contention free period (CFP). A beacon message starts each superframe. The beacon contained the description of the superframe. Each device that receives the beacon can know how the superframe is acting on devices and when devices are able to communicate, and by deducting, sleep.

Preferably, in the proposed Internet of Things stack, illustrated in figure 18, the medium access scheme, no matter which one, has direct access to the PHY management layer 8447 by the mean of the PHY management layer service access points 8446 or 8444. 8446 and 8444, which are the same service access points for all the MAC schemes; they have been separated in the illustration for graphical reasons.

Preferably and still referring to figure 18, the physical layers and the medium access layers used in the wireless mesh network are compliant with the IEEE 802.15.4 8442. As this standard does not cover frequency band such as 433MHz 8450, it is still possible to use the frame format of the standard to increase interoperability of these systems. The frame format is tied to the medium access layer 8437.

Preferably, the Internet of Things networking stack presented in figure 18 integrates the 6L0WPAN protocol. 6L0WPAN 8408 states for IPv6 over low-power wireless personal area network. This is an adaptation layer to support IPv6 communication over IEEE 802.15.4 based communication interfaces. This protocol is composed of three sublayers. The first one is the compression 8413 sublayer, the second one is the fragmentation/reassembly 8419 sublayer and finally, the third one is the mesh framing 8423 sublayer. The mesh sublayer 8424 is actually only a framing sublayer; it does not include the routing algorithm. These sublayers are not all mandatory. For instance, a 6L0WPAN packet may not have a compression 8413 applied on. In such a case, an incoming packet from the IPv6 stack 8411 (going downward to the physical layer) will go directly 8457 to the fragmentation/reassembly sublayer 8420. If that packet is shorter enough to avoid fragmentation 8420, then the 6L0WPAN stack 8408 will directly forward the packet to the mesh sublayer 8423. The mesh sublayer 8423 will work in pair with the routing algorithm in use for that network.

Preferably, the Internet of Things networking stack illustrated in figure 18 manages routing algorithms through a so-called routing management layer 8407. This routing management layer 8407 is an abstraction layer for routing algorithm. Similarly, to the MAC management layer 8437 and the PHY management layer 8447, the Routing management layer 8407 is able to manage instance of routing protocols like LOADng 8405 or RPL 8404. There are multiple routing algorithms, which are candidates for the Internet of Things wireless mesh networks. Two categories of routing algorithms are considered when talking about Internet of Things routing algorithm, depending on where the routing logic is operating. There are the so-called route-over routing algorithms that operate at the Internet Protocol level. The other kind of routing algorithm is called mesh-under. Mesh-under routing algorithms operate more at the medium access control layer. One of the most used route-over routing algorithm is RPL 8404. LOADng 8405 is a mesh-under routing algorithm. LOADng is a lightweight variant of the well-known ad-hoc on-demand distance vector AODV. Routing algorithm can also be categorized depending on their operational mode. For example, there are proactive and reactive algorithms. A proactive routing algorithm, like RPL 8404, will continuously build and maintain routes while a reactive algorithm, like LOADng 8405, will only build routes when required by applications. The routing algorithm operates beside the 6L0WPAN 8408 protocol because the mesh sublayer of the 6L0WPAN stack 8423 requires the routing algorithm using the routing management layer 8407 to deliver a route toward the destination of the 6L0WPAN packet. The routing algorithm will initiate network messages to find the best route toward the specified destination of the packet.

Preferably and referring to figure 18, the routing management layer 8407 has direct access to specific sub-layer service access points. For instance, the routing management layer 8407 can have direct access to the MAC management layer 8433, the unreachability detection layer 8431 as well as the PHY management layer 8447. These direct connections enable optimization of the routing algorithm using passive analysis. Several parameters can be monitoring passively at these different sublayers. For example, the PHY management layer can provide received signal strength indicator (RSSI) and link quality indicator (LQI) for each transmission happening on the radio range of the device. The received signal strength indicator (RSSI) indicates how strong the signal is received by the antenna toward the radio receiver stage. The link quality indicator (LQI) indicates how easy it was to decorrelate the received communication symbols. If a decorrelation is complex, this means that the on-going communication is subject to interferences, and that it is probable that one received symbol is demodulated wrongly. Those two information are useful to know which links toward a node neighbors are the best ones from the physical layer point of view. Other metrics like the link latency or the expected transmission count (ETX) are even more valuable for a mesh network routing algorithm. The expected transmission count (ETX) is a statistic metric that indicates the delivery success rate. With this metric, a device can know how it is probable to have a good transmission. These two metrics - latency and ETX - can be computed by monitoring unicast transmission and retransmission counter from the medium access layer in use. The interaction with the unreachability detection layer is described in the following paragraph.

Preferably and referring to figure 18, the Internet of Things wireless mesh network stack includes an unreachability detection layer 8434. This unreachability detection layer receives unreachability errors from the underlying medium access control scheme in use. The unreachability error is triggered when the maximum number of tries for a transmission has been reached. A major issue when dealing with routing algorithm that operates between a network layer and a medium access layer is that the addressing used throughout the network is sometimes hybrid between IP addresses and MAC addresses. For instance, the MAC scheme in use needs MAC addresses to operate meanwhile the Internet of Things routing algorithm needs IP addresses. When an IP transmission goes at the MAC address layer, the MAC layer loose the reference of the higher application that initiated the transmission. Without that reference, the unreachability errors cannot be handled by the higher-level applications that initiated the transmission. The unreachability error concerns a specific MAC address. The unreachability detection layer 8434 main objective is to track the higher-level application calls in the network and forward unreachability errors triggered by the MAC layer in use.

Preferably and referring to figure 18, the Internet of Things wireless mesh network stack features a dispatch layer 8430. This dispatch layer 8430 is used to route messages within the wireless mesh network stack. This concept is derived from the 6L0WPAN protocol 8408 and has been extended to support the variety of protocols that operate in parallel of the 6L0WPAN protocol 8408 like the multi-application management layer 8425, the routing protocols 8407, and custom proprietary protocols 8417 for device reprogrammation, etc. Specifically to the 6L0WPAN protocol 8408, the dispatch layer is able to directly forward an IPv6 packet to the mesh sublayer 8423, the fragmentation sublayer 8420 or the compression sublayer 8413.

Preferably and referring to figure 18, the Internet of Things wireless mesh network stack have a multi-application management layer 8418. A multi-application network in an industrial Internet of Things paradigm requires the definition of quality of service (QoS) type to drive the responsiveness of specific application at a given time. This multi-application management layer 8418 will manage the quality of services associated with application running on that device. A device part of the Internet of Things paradigm will have multiple application running on it. For example, we distinguish applications that are business-oriented and applications that are system- oriented. Business-oriented applications concerns the business role that a connected object has to achieve. For example, you can consider a connected temperature sensor. The business object in this example is the temperature sensor. The connected statement usually comes from a specific communication module on that business object. The business object will therefore handle all the signal processing to measure the temperature in its vicinity. Then the transmission of that temperature on the network is a matter of business application. Conversely, system-oriented applications would be the firmware over-the-air reprogramming, the mesh routing algorithm control messages, etc. By differentiating these two kinds of applications, it is then simple to give a specific business object a given quality of service while maintaining network and system traffic apart with different qualities of service.

Preferably, the Internet of Things multi-application wireless mesh network stack is connected with a central management system. This central management system knows about each of the applications available in the network it manages. For instance, it knows about all the system-oriented application as well as custom business-oriented application.

Preferably, the Internet of Things wireless mesh network stack includes a firmware over-the-air (FOTA) reprogramming system. This FOTA system preferably operates within the Internet of Things wireless mesh network for the firmware transmission in the mesh. Preferably and referring to figure 19, the firmware over-the-air (FOTA) reprogramming system is divided into two level of software. A first level of software would be a general reprogramming agent 8653 that manages any incoming packets from the network used for the reprogramming 8652, 8656 and 8657. A second level of software would be a communication interface specific piece of software that manages the transfer of the new firmware optimally for that particular communication interface 8651 , 8655 and 8657. This is particularly important in the case of the wireless mesh network due to the limited bandwidth and low-rate capability of the network 8651. For any communication interfaces, the MTU is driving how the firmware updates will be disseminated. For other interfaces such as Ethernet communication interface or GSM/GPRS communication interface, the MTU is bigger of an order 10-15 times the MTU of a low-rate and low-power wireless mesh network. Especially for the Ethernet communication interface, the available throughput is also higher than GSM/GPRS communication interface. This will lead to a faster download of the firmware, both in terms of transmission speed and payload size. The FOTA agent 8653 operates closely with a memory manager 8661 so that the received updates are persisted. The memory agent 8661 will work in conjunction with a memory driver 8670 to persist information physically. Within the wireless mesh network, the firmware update packets are managed by the device and network management agent 8664. The wireless mesh network 8671 benefits from using a dedicated protocol 8664 for the firmware update management, this dedicated protocol runs within the Internet of Things adaptation stack. With this dedicated protocol, the transfer can be more efficient than going through transport layer protocols

Qualities of Service

Introduction

Referring to figure 21 , there are two levels of service qualities in the common core electronic multi-role module for the Internet of Things. The first quality of service operates at an application level while the other quality of service operates at the network level. The application-level quality of service operates at the homogeneous communication interface (HCI) introduced before. It provides the ability of routing application network traffic by selecting the most appropriate gateway in the wireless mesh network. The network qualities of service 8751 8756 8760 8764 provide the system the ability to prioritize some network traffics 8752 8755 8762 8763 among others. The application qualities of service will be now referred to as homogeneous communication interface (HCI) quality of service (QoS), shortly HCI QoS. Similarly, the network qualities of service will be now referred to as network QoS. The common core electronic multi-role module for the Internet of Things has several important components. Among these important components, there are the potentially multiple network interfaces 8766, the Internet protocol stack 8716, the homogeneous communication interface (HCI) 8709, the applications 8707 8720 8731 like HTTP client or server, the resources index 8700 and the memory 8746. The resource index 8700 manages a list of resources 8733 8701. Each resource has metadata 8734 that describe the resource. Example metadata are the name of the resource, the unit associated with that resource, an identifier, a type of resources, and a category of resource like system, sensor, io, external, etc. A type of resource typically describes how a resource is represented, for example as an integer value, as a double value or as a string. A resource has a list of values 8738 saved in a history 8737. Each value is time stamped with optional flags indicating if that value has been synchronized or not with remote servers. A quality of service information is also added to the resource's metadata 8735. The resources index 8700 is not only synchronized with remote server, but also internally 8745 with a memory 8746. Embedded applications 8707 are mapped with the resources index 8700 so that a direct access is possible with the different application protocols and provide consistent data. Embedded applications are likely to have the same internal architecture, including a connection management 8704, a protocol implementation 8705 and the interface 8706 towards 8702 the resources index 8700. An application protocol 8705 will carry the resources index 8700 information accordingly to the received 8708 requests. A set of standard data formats 8711 is provided by the system for all the embedded applications. Typical formats 8711 used in the Internet of Things are JSON 8710, CSV 8712 or even XML 8713 but the latter one is usually considered too verbose and generates large payload the low-rate network has to carry. JSON 8710 format states for JavaScript Object Notation, which is an open standard format that an alternative to the XML 8713 format used in web protocols. XML format 8713 states for Extensible Markup Language, which is also an open standard based on tags rather than a key/value approach. Both the JSON 8710 and XML 8713 formats are considered human-readable. The CSV format 8712 states for comma-separated values. This format is efficient when transmitting sets of data because the overhead for the structure is used once only. With this architecture, the content is seamlessly delivered 8708 through the different communication interfaces 8766 managed by the homogeneous communication interface (HCI) 8709. This means that a Bluetooth compliant device can access exactly the same data as an HTTP client running on top of an Ethernet link or wireless mesh network. The homogeneous communication interface (HCI) will adapt the way the data are packed to suit the used communication interface.

Preferably and referring to figure 21 , devices in a wireless mesh network 8796 that include the homogeneous communication interface (HCI) have a shared state 8715 8796 about the gateways available in that network 8796. A gateway is a device that has an interface for the wireless mesh network and at least one interface for Internet- oriented communication interfaces like Ethernet or GSM/GPRS. A Bluetooth communication interface is not considered as an Internet oriented communication interface and is managed directly 8714 8722 8741 by the homogeneous communication interface (HCI) 8709 8719 8729.

Preferably and referring to figure 21 , a common core electronic multi-role module for the Internet that is acting as a gateway must respond to wireless mesh node featuring the homogeneous communication interface that searches for available gateways. The wireless mesh nodes will search gateways using the IPv6 all-router multicast address. This address is automatically assigned to the wireless mesh network communication interface 8785 by the common core electronic multi-role module at startup when it detects that an Internet-oriented communication interface 8792 is available. A wireless mesh node in the network will use its homogeneous communication interface (HCI) in order to ask for routers. This research of routers being in the network uses an all- router multicast address. Once gateway addresses are found, then the homogeneous communication interface (HCI) will ask these gateways about their communication interface available.

Preferably and referring to figure 21 , a common core electronic multi-role module for the Internet of Things that includes a wireless mesh network interface with multi- application capability have the following components: a physical layer and a medium access control layer; an unreachability detection layer 8758 to manage mesh routing errors and their dissemination; a dispatch layer 8751 to manage the medium multiplexing of low-layer protocols; and the low-layers protocols such as the mesh routing algorithm 8749, the IPv6 adaptation layer 8757 for the low-rate wireless network and other proprietary protocols 8761 and 8765. To support the multi- application capability of the wireless mesh network interface, the dispatch layer 8751 manages the network qualities of services 8751 8756 8760 8764. These qualities of service are assigned per low-layer applications 8748 8757 8761 8765 but managed by a dedicated component, the multi-application management layer 8765. These qualities of service are used by the medium access control (MAC) layer to prioritize network traffic flows coming from these low-layer applications blocks. For example, the traffic 8755 concerning the 6L0WPAN 8757 component could have a lower quality of service value (priority) than the traffic 8752 for the routing algorithm 8749. The medium access control (MAC) layer will therefore check the qualities of services of pending messages and decide which packet it has to transmit now. There is a small coupling between the qualities of services 8751 8756 8760 8764 defined at the dispatch layer 8751 and the way these packets are managed by the medium access control (MAC) layer 8759. This coupling is associated to the internal data structure that manages network packet.

Preferably and referring to the figure 21 , the network quality of service 8756 associated with the 6L0WPAN component 8757 of the wireless mesh network communication interface could be considered as the device business-oriented application traffic flow. The device business-oriented application traffic flow would be for a street light the messages used to get measures from the streetlights or commands sent to control that streetlight. This simplifies the way the multi-application capability of the wireless mesh network is managed. However, the traffic coming from or going to the 6L0WPAN interface is not only dedicated to the business part of the connected object, some traffic is also generated by system component based on the upper-layer Internet protocols and interaction with the central management system. This does not affect the way that network traffic is managed by the wireless mesh network lower layer. For example, an intermediary device that receives a frame 8771 in the medium access control (MAC) layer will check it 8769 with the routing layer 8767 to define if that frame destination is that intermediary node or another node. If the received frame is not destined to that intermediary node, it will push 8774 that frame in the transmission queue 8777 of the medium access control layer with some additional operations. Among these additional operations to forward 8774 a frame from one node to the other, there is the update of the frame with the routing layer information 8767. For instance, there is the source and destination addresses at the medium access layer (MAC) level that need to be updated with the intermediary device own MAC address as the source of the message and the destination address of the frame with the next-hop address given by the routing algorithm. If a frame targets the intermediary device, then the frame will be pushed to the higher-layers. If this is an application level packets, the frame will go up to the application layer through 8770 the 6L0WPAN layer 8772, the Internet protocol stack 8721 8716, and the homogeneous communication interface (HCI) 8717 8719. The interaction between the 6L0WPAN layer, the routing layer and the unreachability detection layer allows the system to consider the originator's application quality of service in intermediary devices. For example, the unreachability detection layer uses the first fragment of a huge IPv6 packet to know the IP address of the destination as well as the IP address of the originator. This is what allows an intermediary node to send an error message toward the originator of a packet to clean a broken route. This state manager is also able to manage the quality of service associated with that IPv6 packet. Indeed, the quality of service information is carried within a standard IPv6 header field named Traffic class for backward compliance and interoperability.

Preferably and referring to the figure 21 , an intermediary device in a wireless mesh network can use its own resources index 8725 to monitor how the traffic is forwarded through that intermediary device and synchronize these monitoring information with a remote server for network diagnostic.

Preferably, the common core electronic multi-role module for the Internet of Things includes a parameter index. The parameter index is a set of list of parameters. System major components can create a list of parameters and register it into the parameter index. Other system components can listen to a specific list of parameters and be notified when a parameter within that list has been changed. This notification allows the system to reinitialize specific components when values have been updated without performing a complex program that synchronizes this for the entire system.

Preferably, the common core electronic multi-role module for the Internet of Things with a parameter index is able to deliver the parameter index content through the communication interfaces managed by the homogeneous communication interface (HCI). This ensures that the parameter index is available to all the supported communication interfaces and protocols.

Preferably, the common core electronic multi-role module for the Internet of Things with a parameter index is able to check new parameter value with specific constraints, for example a new value not well formatted or an unsupported new value.

Preferably, the common core electronic multi-role module for the Internet of Things with a parameter index allows specific parameters to be updated while other specific parameters to be read-only.

Resources with the same destination but different qualities of service

Preferably and referring to figure 21 , an embedded application 8706 within the common core electronic multi-role module uses the resources index 8700 to synchronize several resources with a remote server. If the resources that are under synchronization with the same remote server have different homogeneous communication interface (HCI) qualities of service, then the quality of service with the more restricted parameter is chosen.

Preferably and referring to figure 21 , an embedded application 8706 within the common core electronic multi-role module that uses the resources index to synchronize several resources with a remote server can create multiple communication flows toward different gateways to comply with defined qualities of service. For example, one flow can use high-priority traffic to go toward a closest gateway but with costly communication interface as GSM/GPRS traffic for example, rather than a free gateway that is farer.

Preferably, the homogeneous communication interface defines the number of connections necessary to synchronize a set of resources with a single destination using the average data load generated by the source of the data. For example, if some resources are fed every second with a new integer value and a synchronization is performed every 5 seconds, then such a situation would generate network transaction with some fragmentation. Values are formatted using a standard format like JSON for example. Then values are also time-stamped with some meta-data and header information. The resulting payload quickly become more than 50 bytes per value, which roughly represents the payload available for a service packet data unit of the medium access control layer for the IEEE 802.15.4 technology. Therefore, the homogeneous communication interface decision needs to monitor the amount of data generated for the synchronization of every resource in the system to define if yes or no an existing connection can be reused or not.

Preferably, the homogeneous communication interface sorts the resources associated quality of service and groups them by similarity and predicted network load. The network load can be predicted by analyzing the average interval between two new values registered in the resource and the size necessary to carry that value with the selected format as well as the general resource header information.

Preferably, the homogeneous communication interface includes in the network load induced by a resource being synchronized the transport protocol overhead estimation. For example, using TCP-based protocol automatically induces a protocol overhead for the connection management, typically keep-alive traffic.

Preferably, an embedded application within the common core electronic multi-role module for the Internet of Things that is configured for periodic synchronization with several resources having different associated qualities of service should first synchronize the resources having the better quality of service configured. If multiple resources have the same or similar quality of service associated, then the homogeneous communication interface can group them to synchronize them using a single network connection toward the appropriate gateway within the wireless mesh network. If a group of resources having similar but not exactly the same qualities of service defined becomes larger than 10 resources, then the group of resources is splitted to use new connections to handle each quality of service and their associated resources. Preferably, a connection managed at least 5 resources before allowing the creation of a new connection.

Preferably, the homogeneous communication interface (HCI) of a multi-role communication module also handles specific routing constraints to group resources. If a resource has a routing constraint telling that it should not use GSM/GPRS connection for a synchronization and other resources of that device have that GSM/GPRS connection preferred, then two connections are opened: one of the at least one constraint resource, on the other for the rest of the resources.

Preferably, the homogeneous communication interface (HCI) also considers the average load of a gateway to route its network packets. For example, if a gateway load level is reaching a warning threshold, then devices will have to smooth their use of that gateway by rerouting part of the network traffic towards another less used gateway. Special care must be taken for the convergence time in the network. The gateway state is shared between the wireless mesh network nodes periodically or when an important change is measured.

Preferably, the homogeneous communication interface (HCI) searches the wireless mesh network available gateways periodically. The period of gateway research should be a factor of the mobility rate of the wireless mesh network. For example, if the network is relatively mobile, which means that a device moves from 500 meters in a minute, then the network have a fast mobility rate. Preferably, the wireless mesh network routing algorithm is driven by the mobility of the devices within that wireless mesh network. For example, a mesh network with devices moving at a rate less than 2 meters per second is a low mobility network. If devices are moving at a rate between 2 to less than 5 meters per second, this is a medium mobility. Finally, if devices are moving at a rate higher than 5 meters per second, this is a high mobility situation. The route lifetime are factor of the medium access control layer scheme.

Preferably, the multi-application network based on a wireless mesh network uses a two level network architecture. The first level of the architecture is the wireless mesh network backbone of full function device. The second level of the architecture is a wireless star network with a full function device part of the wireless mesh backbone network and being a reduced function device.

Preferably, the multi-application network with a backbone wireless mesh network uses asymmetric cryptography to deliver session security parameters between the mesh routers of the network. The session security parameters are generated either from the ad-hoc gateway, either from the central management system on which the gateway is connected to. These session security parameters are maintained as defined until a device is revoked from the network, until a specific timeout has expired or until manual operations within the system. Otherwise, the network re-uses the existing security parameters to prevent long association and network creation time.

Preferably, the multi-application network using wireless mesh network with full function devices as backbone operators and reduced function devices connecting in star topology to the mesh backbone network uses one-to-one cryptography between the full function device and the reduced function device. This supposes that the traffic being carried between this one-to-one link between the full function device and the reduced function device must be decrypted and encrypted again using the wireless mesh network securities.

Preferably, the multi-application network using wireless mesh network with full function device and star topology from reduced function device towards full function device of that wireless mesh network have low mobility in the full function devices and low to high mobility for the reduced function devices. This limits the security traffic over the wireless mesh network by keeping the reduced function device associated local.

Gateway operations with multi-application over wireless mesh network

Preferably, and referring to figure 21 , a common core electronic multi-role module for the Internet of Things acting as a gateway in a wireless mesh network supporting multi-application will receive packets from the wireless mesh network. These incoming packets are most of the time willing to reach a destination in the global Internet network. Therefore, the role of the gateway device is to forward this traffic on an Internet-oriented communication interface with the required operations. Typically, this forwarding operation will be managed by the embedded Internet protocol layer. However, in some cases, specific protocols operating within a low-rate and low-power network use optimized version of Internet protocol that requires adaptation prior to forward in the global Internet. For instance, there is an optimized version of HTTP that usually runs on top of TCP transport layer protocol that uses UDP instead and compression mechanisms to lower the protocol overhead. The gateway device also includes proxy of translation for these specific optimized protocols. It is therefore not impossible that internal traffic of the wireless mesh network indirectly targets a proxy gateway to reach a remote server on the Internet.

Memory implementation of Resources

Preferably and referring to figure 20, a common core electronic multi-role module for the Internet of Things that includes an index of resources 8600 persists the resources' values 8614 within a memory 8605. Preferably, the memory 8605 used to store resources index values is a flash memory. A resource 8601 is a generic data container that provides storage ability with history 8612 and time stamping capabilities for each value 8614 or 8616 for example. The resources index 8600 will synchronize the content of a resource within the embedded memory 8605. The embedded memory is composed of blocks like 8605, sectors like 8604 or 8606 and pages like 8608, 8610 and 8611. Usually, embedded memories limit the different kinds of operation to one or several level like blocks, sectors, and pages. For instance, erasing a part of the memory is sometimes only possible on blocks and sectors. Typically, a resource 8601 will get sectors like 8607 from the embedded memory in which it can stores its values in pages like 8608, 8610 or 8611. A resource will get some sectors of the memory to store its values. The resource structures are stored in another part of the memory, typically reserved sectors. A resource can manage a list of ordered but potentially non-adjacent memory sectors. This list of sectors per resource is cyclic, which means that once a resource memory is full, it will loop to erase the older values automatically. To optimize the memory lifetime, once a loop is made to erase an older value, the entire sector in which that value is stored is erased and reinitialized to a writeable state. For instance, with a flash memory, one can only write on a sector or page basis if the state of the memory is cleaned. One cannot change a 1 in the memory by a 0 by simply reprogramming that bit, one has to clean the whole page or sector to do so. Therefore, by erasing directly the older sector of a resource, then one only cleans the memory once and can write values as they come in sequence in a clean state.

Backbone network

Preferably, the wireless mesh network can act as a backbone for reduced function devices - leaf node in the wireless mesh network. The backbone wireless mesh network can operate on a different technology than the network for the reduced function devices. For instance, you can have an 868MHz wireless mesh network for the backbone network and a 433MHz network for the leaf nodes. The node being part of the wireless mesh network will map the transaction from one interface to the other while taking into account routing problematic. This situation enables the node to act as an access point in star-topology for reduced function devices. Typically, having two different communication technologies for this situation allows the system to use another medium access control layer for the reduced function devices, using for example TDMA MAC scheme rather than a CSMA. The TDMA MAC scheme allows the device to operate efficiently in battery-based power supply. For example, in the context of a smart-city and referring to figure 24, you can have a gateway 8050 on the roof of a building with an Internet access. That gateway manages the node of the wireless mesh network, in this example; those are the streetlights 8061 , 8067 and 8053. Finally, each streetlight can manage some reduced function device. For instance, the streetlight 8061 can manage 8060 and 8062 the reduced function devices 8059 and 8063 by the mean of the same radio interface of the wireless mesh network, or by the mean of a dedicated and optimized communication interface. Referring now to the figure 25, the architecture proposed in the example of figure 24 have the Internet connectivity available 8000, the wireless mesh network 8009 made of gateways 8004 8003 and router nodes 8008 8007. The wireless mesh network 8009 is made using connections between gateways and nodes 8005 8006 and nodes to nodes 8014 8017. The router nodes 8007 can then act as access points 8010 for reduced function devices 8012 8013. The technology used for the connection 8010 8011 between the router node and the reduced function device can be the same technology used for the entire wireless mesh network, or another technology with specific parameters and access schemes.

Security considerations with backbone network and RFD

Preferably, and referring to figure 22, the integration of reduced function devices within a wireless mesh network uses ad-hoc security parameters. A reduced function device is a device that cannot route network traffic for other nodes; it acts as a leaf in the wireless mesh network. Consider a multi-role node in the wireless mesh network acting as a gateway 8827. That node 8827 will transfer traffic coming or going to the wireless mesh network 8822 with the Internet network using one of the Internet- oriented interfaces 8829 like Ethernet 8828 or GSM/GPRS 8830 for example. The wireless mesh network in this example is composed of the devices 8810, 8817 and the gateway 8827. This wireless mesh network shares a common security domain. That wireless mesh network 8833 can act as an Internet of Things backbone for reduced function devices 8803. To prevent the rebuilding of the whole security domain of the wireless mesh network 8831 once a reduced function device 8803 is stolen, broken, or compromised in a more general manner, the proposition is to use ad-hoc securities 8832 between reduced function devices 8803 and an intermediary node 8810 part of the wireless mesh network 8833. This leads to an ad-hoc security domain 8800 for that particular reduced function device 8803. This ad-hoc security domain 8800 is generated by the intermediary device 8810 that connects the reduced function device 8803 to the backbone wireless mesh network 8833. The reduced function device 8803 and the router device 8810 use the same private/public infrastructure within the object to exchange the security information of that ad-hoc security domain 8800. The private/public key security information can be filled at the provisioning using the human to machine interface like Bluetooth 8806. Once the reduced function device has been commissioned in the system, it can try an association on a router device, which will forward the association mechanism

Preferably and referring to figure 22, a router role device 8810 on which a reduced function device 8803 attempts to connect can provide an ad-hoc security code for the leaf-node 8803 through the human-to-machine embedded interface 8813 or through the wireless mesh network 8833 in a central management system. Once the installer get this ad-hoc security code, it can provision the reduced function device 8803 with that code using the embedded human-to-machine interface like the Bluetooth interface 8806. Thanks to this ad-hoc security code, the reduced function device 8803 is able to communicate securely 8800 with the router device 8810 without having to negotiate security keys through the network 8833. The association process remains the same. Once the device is associated, then the security is activated between the pair 8810 and 8803.

Preferably and referring to figure 22, the node as a gateway 8827 also includes the homogeneous communication interface (HCI) 8825 so that the nodes in the wireless mesh 8817 or 8810 can know about this gateway and decide which of these gateways is appropriate for their use. This is possible because of the shared state 8807, 8814 and 8821 between the different homogeneous communication interfaces (HCI) 8815, 8808 and 8805 in the different device of the wireless mesh network.