The introduction of a Gateway entity in the M2M architecture of IOT-A aims at resolving is- sues regarding the interworking between different protocol stacks and access technologies. In this context the translation functionality ensures interoperability between user domain ap- plications that are normally located in unconstrained networks (e.g., Internet network) and “things” that in many cases communicate and reside within constrained networks. Further- more, the communication among things of different technology domains shall be supported to the maximum possible extent, through the definition of a common set of concepts and semantics between the two domains.
Refer to Fig.18, where we refer again to communication scenario S2. The operations carried out by the protocol translation components reside in the Gateway (terminal of type TT1) and
take place in the upper part of the protocol stack, thus involving the M2M communication layer. Hence, the Gateway should have all networking layers (from PHY up to and including TRA) plus the required application (M2M) layers. In this case, we refer to “application-layer Gateway”, as per our discussion in Section7.3.1.3. For this example, at the IoT constrained node we use CoAP as it is amongst the most lightweight M2M protocols.
IoT-A DPWS CoAP IoT-A UPNP CoAP IoT-A HTTP CoAP Gateway NTU NTC M2M Protocol Translation Cases CoAP CoAP HTTP UPNP DPWS Case 1: Case 3: Case 2: Case 4: CoAP CoAP CoAP IoT Constrained Node Unconstrained Node
Figure 18: Translation among different M2M standards for communication scenario S2.
For simplicity, but without loss of generality imagine that the unconstrained node in the NTU aims at communicating with a resource constrained IoT node in the NTC domain on the right. Given this, we can foresee four possible cases:
• Case 1 - “Transparent M2M Gateway”: unconstrained and constrained IoT devices both adopt the same M2M language. In this case no translation is needed and the Gateway only has to take care of performing protocol translation for the lower layers, PHY, MAC and possibly NWK and TRA. PHY and MAC translation is what normally any IP gateway does, which consists of interfacing different PHY-layer communication technologies. NWK adaptation when IPv6 is used within the unconstrained network domain consists of translating IPv6 packets into 6LoWPAN packets, as discussed in Section 7.3.3. This functionality has been standardized by IETF, see [30]. At the transport (TRA) layer, there might be the need of interfacing the specific transport protocol adopted within the constrained domain with that used within the unconstrained network domain (that is usually TCP), see Section7.6below for a more details on this.
• Case 2 - “HTTP to CoAP Translation”: the unconstrained node on the left-hand side of Fig. 18 exploits HTTP at the M2M layer, whereas the IoT device uses CoAP, which works according to a similar paradigm but has a reduced set of functionalities with respect to HTTP. In this first case, some translation is necessary to concert HTTP messages into CoAP ones and vice-versa. This translation can occur at the Gateway node or elsewhere in a proxy server (referred to as “translation proxy”). This func- tionality is being standardized within IETF, see [35]. Note that this protocol translation case entails a lightweight protocol association mechanism as CoAP is a simplified ver- sion of HTTP and for most cases there is aone-to-one mapping between M2M control messages. This entails the compression of HTTP header fields for their representation within the CoAP protocol domain.
• Cases 3/4 - “UPnP/DPWS to CoAP Translation”: in these cases there is no direct association between the control messages of the involved M2M protocols. Here, the Gateway maps every discovered IoT device into anabstract representationaccording to theIoT-A information model and since there will be a mapping scheme between every technology domain and the IoT-A information model, inter-domain publication and discovery will be possible. The trick is thus the following: whenever direct M2M communication is not possible the Gateway (this functionality can be also moved into a translation proxy) is in charge of representing the “things” that are under its jurisdiction into a standard “IoT-A format”. From there, any M2M technology can thus be mapped toward IoT-A to ensure end-to-end communication across different M2M domains. According to the above concepts the role of the Gateway in the above example can be summarized as follows:
• The Gateway offers a number of interfaces addressing standard physical layer commu- nication interfaces such as Ethernet, Wireless LAN and ADSL. The set of supported physical layers can be extended by plugging dongles implementing additional commu- nication protocols (ZigBee) and physical interfaces such as IEEE 802.15.4 or KNX. The standard networking protocols are deployed and configured for each interface. • Constrained network protocols such as 6LoWPAN are also available over the wireless
interface.
• All communication interfaces are made available to the application framework of the Gateway.
• This framework can be extended by the deployment of specificapplication bundlesthat regard specific M2M protocols and architectures such as UPnP, DPWS, CoAP. These can enumerate available resources of the relevant domain either by following any avail- able discovery procedures of the specific technology domain or by being associated with any resources that cannot be automatically discovered.
• All the resources are mapped to the common IoT-A information model so that a unified registry is maintained for each resource.
• All the entries in the registry can be published (where this is feasible) for each of the technology domains supported by the Gateway.
• The Gateway shall provide routing capabilities for all physical interfaces.
• In case no protocol translation is required the Gateway simply bridges different physical layer interfaces.
• The Gateway will support forwarding of transport protocols (e.g., CoAP) from uncon- strained networks (e.g., IP) to constrained networks by applying the compression of IPv6 headers (through 6LoWPAN), if the communication scenario so requires.
• The above IoT-A unified representation will allow the support for protocol translation
(e.g., HTTP to CoAP) or more complex interworking/relaying functionalities (e.g., UPnP/DPWS to CoAP).
• The Gateway will be also supporting tunneling associations that connect remote con- strained networks using the same networking and transport protocols.
7.5.1 Security considerations
We remark that mandatory functionalities for the Gateway are physical layer interfacing, IPv6 compression (e.g., 6LoWPAN), whereas M2M translation can be alternatively moved to atranslation proxy, which can be positioned within the unconstrained network. In this case we have two possibilities:
1. The unconstrained node does not know about this translation proxy: in this case this node will send its packets to the Gateway, which will understand that some translation is needed. Thus, the Gateway will forward all the M2M traffic that needs translation to the translation proxy (e.g., UPnP control messages), which will return to the Gateway the corresponding messages in a language that the IoT devices understand (e.g., CoAP). The Gateway will finally forward these latter messages to the IoT resources. The same procedure is implemented in the opposite communication direction (IoT node → un- constrained node). In this case the Gateway will be responsible for: 1) managing the communication with the proxy for the execution of its translation service, 2) performing the needed translations at physical and network (e.g., 6LoWPAN) layers.
2. The unconstrained node knows about the translation proxy: in this case the uncon- strained node could communicate directly to the translation proxy, that will impersonate the final Gateway. Here, the proxy will translate the relevant M2M messages received from the unconstrained node and forward the translated flow to the Gateway. In this case the Gateway will only have to perform the needed translations at physical and network (e.g., 6LoWPAN) layers.
Note that both scenarios have their peculiarities in terms of security. The first case in fact implies that the Gateway is trusted and has the security material needed to understand (i.e., decrypt) the content of those packets that need M2M translation. The second case
does not necessarily require that the Gateway be trusted. However, in this second casethe proxy must be trusted.
Also, for cases 1 and 2 of the previous Section 7.5, in Section 8 we detail a practical (and novel) procedure that exploits IPsec-EPS (network-layer security) and that is lightweight enough to be implemented in most tiny and resource constrained IoT devices. The secu- rity actions for cases 3 and 4 are computationally heavier: UPnP itself will in fact hardly natively implemented by IoT devices, due to their resource limitations, for DPWS, we note that this standards adopts HTTPs, which could be too heavy for most IoT devices. In these cases, a way to provide end-to-end security would be to split the connection at the Gate- way. Thus, the Gateway will use UPnP (or DPWS) to provide a secure channel from itself to the unconstrained node and a more lightweight procedure will be exploited to secure the communication channel within the constrained network domain. In this last scenario the Gateway must be trusted and perform all the required mappings during the entire communi- cation. Instead, in cases 1 and 2 the Gateway could only be involved in the initial setup of the communication channel, leading to a true end-to-end secure channel between the peers (see the implementation details in Section7.5).