Recommended
More Related Content
What's hot
What's hot (20)
Similar to A Bridging VPN for Connecting WSNs to Data Centers
Similar to A Bridging VPN for Connecting WSNs to Data Centers (20)
Recently uploaded
Recently uploaded (20)
A Bridging VPN for Connecting WSNs to Data Centers
- 1. Copyright © NTT Communications Corporation. All rights reserved. ntt.com Transform your business, transcend expectations with our technologically advanced solutions. A Bridging VPN for Connecting Wireless Sensor Networks to Data Centers Hiroaki Hata NTT Com Engineering
- 2. Copyright © NTT Communications Corporation. All rights reserved. • Wireless Sensor Networks; WSNs – has a long history • IoT – Internet connection cost is decreasing • Questions – Should Wireless Sensor Networks be adapted to an IP network ? – Nevertheless, IP is not essential. Background and Motivation 2
- 3. Copyright © NTT Communications Corporation. All rights reserved. Issue of Scalability of Wireless Sensor Networks Internet or IP-VPN Data Centers Wireless Sensor Networks Wireless Sensor Networks Wireless Sensor Networks Wireless Sensor Networks Wireless Sensor Networks Globally Distributed Wireless Networks should be connected to Data Centers Data Link Networks(LAN)Network Layer(WAN) WSNs 3 How should we connect to?
- 4. Copyright © NTT Communications Corporation. All rights reserved. Existing Approach to Scalability of Sensor LAN Internet or IP-VPN Data Centers WSN Existing Approach : IP Initiative Identification of sensor terminals - IP or URL. IP Gateways in WSNs or IP Stack on Terminals IP World IP World Invasion Increasing IoT costs 4
- 5. Copyright © NTT Communications Corporation. All rights reserved. Our Proposed Approach Data Centers WSN IP World non - IP World IP network extends the Data Links of the WSNs instead of invasion. Data Link Bridging Data Center Application and WSN are not required to adapt to IP 5
- 6. Copyright © NTT Communications Corporation. All rights reserved. non IP Data Processing Applications Inter- net/VPN Development in Lab. Full Scale Start Business Scale up Application Range of our Proposal non-IP WSN Sensor Terminals Small Start up non IP Data Processing Applications non- IP WSN Internet/VPN IP WSN IP Data Processing Applications Proposed Approach Existing Approach 6
- 7. Copyright © NTT Communications Corporation. All rights reserved. Design Goal of our Proposal Backbone for WSN • Bridging – instead of Gateway or IP-Interconnecting – WSN devices and applications do not need to be adapted/modified to IP for IoT. • Scaling – Multiple WSNs can be connected to a Data Center IoT CAPEX Reduction 7
- 8. Copyright © NTT Communications Corporation. All rights reserved. Application IP L2 over IP Tunnel /dev/ttysocket UART Reader /dev/tty IP Tunnel ProcessUART Reader socket Data Center Side WSN PAN WSN PAN UART Serial Bridging Software by IP network Tunnel Server on Data Center Side UARTUART Tunnel Client on WSN Application UART UART 8UART; Universal Asynchronous Receiver/Transmitter on a serial interface
- 9. Copyright © NTT Communications Corporation. All rights reserved. Appli- cation PAN1 PAN2 PAN３ Tunnel Server PAN Consolidation PAN1 PAN2 PAN３ Application should choose the output interface for L2 data frames Modification of the Application is required. Violation of the Design Goal. Backbone routes L2 frames. Application regards to connect one large PAN. P2P Bridge Connections by multiple ports PAN Consolidation tty0 tty1 tty2 tty0 Tunnel Server Tunnel Server Tunnel Server Appli- cation Consolidated PAN 9
- 10. Copyright © NTT Communications Corporation. All rights reserved. Targeted WSN MAC PDU non IP Data Processing Applications root • MAC Address is embedded in Data Frames Inner nodes and leaves Data Link Frame 10
- 11. Copyright © NTT Communications Corporation. All rights reserved. Appli- cation A0 A1 A2 A3 Data A3 T1 T2 T3MAC Address Tunnel Id A0 T1 A1 T1 A2 T1 A3 T1 B0 T2 C0 T3 B C Frame Dest. is A3 Transfer to T1 Routing Table Tunnel Server look up A0,A1,A2,A3 Connecting （Step 2）Forming a Routing Table by Notifications of MAC Address （Step 3）Look up Routing Table by Dest. MAC Addr. in L2 Frame and Transfer to Dest. Tunnel Tunnel Server Routing – Scaling up （Step 1）Setup an IP Tunnel Connection between Tunnel Servers and Clients PAN1 PAN2 PAN3 11 Tunnel Client Tunnel Client Tunnel Client
- 12. Copyright © NTT Communications Corporation. All rights reserved. T2 T1 A0 A1 A2 B1 B2 B0 B3 Tunnel Server A A0 Application A Application B PAN A Pan is shared by two Owners, A and B Each Owner Sets up an IP Tunnel from the Tunnel Client to the Data Center and Set MAC Addresses of Terminals in the Routing Table. Look up Routing Table by Src. MAC Addr. in L2 Frame and Transfer to Dest. Tunnel Tunnel Client Routing -Sharing Tunnel Server B Tunnel Client MAC Tunnel A0 T1 A1 T1 A2 T1 B0 T2 B1 T2 B2 T2 B3 T2 Routing Table 12
- 13. Copyright © NTT Communications Corporation. All rights reserved. T2 T1 A0 A1 A2 B1 B2 B0 B3 Tunnel Server A A0 Application A Application B PAN A Pan is shared by two Owners, A and B Each Owner Sets up an IP Tunnel from the Tunnel Client to the Data Center and Set MAC Addresses of Terminals in the Routing Table. Look up Routing Table by Src. MAC Addr. in L2 Frame and Transfer to Dest. Tunnel Tunnel Client Routing -Sharing Tunnel Server B Tunnel Client MAC Tunnel A0 T1 A1 T1 A2 T1 B0 T2 B1 T2 B2 T2 B3 T2 Routing Table 13
- 14. Copyright © NTT Communications Corporation. All rights reserved. Tunnel Server Routing A1 A2 B1 B2 B0 B3 A0 PAN Applica- tion by Dest. MAC Address Routed by Where the Terminal is connected by Src. MAC Address Routed by Who owns the Terminal Set of 3 tuple (MAC Address, Owner, PAN-ID) can form routing tables Combination of Two Routings Tunnel Client Routing 14
- 15. Copyright © NTT Communications Corporation. All rights reserved. PAN 1-A PAN 1-B PAN 1-C PAN 2-A PAN 2-B PAN 2-C PAN 3-A PAN 3-B PAN 3-C Mesh overlay bridging Tunnel ClientTunnel Server Application A Application B Application C PAN1 PAN2 PAN3 15
- 16. Copyright © NTT Communications Corporation. All rights reserved. PAN 1-A PAN 1-B PAN 1-C PAN 2-A PAN 2-B PAN 2-C PAN 3-A PAN 3-B PAN 3-C Problems on implementation Tunnel ClientTunnel Server Application A Application B Application C PAN1 PAN2 PAN3 Overload to routing on Tunnel Client Application Server cannot be located inside NAT Leak of Routing Table and Tunnel Information 16
- 17. Copyright © NTT Communications Corporation. All rights reserved. PAN 1-A PAN 1-B PAN 1-C PAN 2-A PAN 2-B PAN 2-C PAN 3-A PAN 3-B PAN 3-C Introducing of Switching Server Tunnel ClientTunnel Server Application A Application B Application C PAN1 PAN2 PAN3 Switch Server -Tunnels are set up from both sides. -Routing Tables are located at Switching Server 17
- 18. Copyright © NTT Communications Corporation. All rights reserved. 3 tuple (MAC, Owner-ID,PAN-ID) Controller Owner Introduction of SDN Architecture MAC→Owner Tunnel-ID MAC→PAN Tunnel-ID PAN Side Routing Table Owner Side Routing Table Switching Server Tunnel Clients Tunnel Servers 18
- 19. Copyright © NTT Communications Corporation. All rights reserved. Possible Service A’s Terminal Bridging VPN Backbone Data Processing Application Controller MAC,Owner,PAN (1)Register MAC Infos. (2)Settle the Terminal on the PAN (3)Allowed to Access to A’s Terminal Accessible Shared PAN User A Computer B’s Terminal Forbidden Switching Server TTY tap device driver Tunnel Server /dev/tty 19 Access Points/ Tunnel Clients
- 20. Copyright © NTT Communications Corporation. All rights reserved. Conclusion • We proposed a L2(Serial) bridging VPN – for small start business of IoT providers. • Two different approaches to IoT – by IP, IP aware; IP application and IP terminals. – by using IP; IP acts behind the scene. 20
Editor's Notes
- Good afternoon,/ Today/ I’d like to present our new concept /for IoT backbone network. ///This presentation /covers just the concept, /and does not include the results of experiments /or any evaluation. ///We hope to implement software of this network system some time this year. ///So I expect to be able to present the evaluation /next time. //But for now, /let me explain our progress so far.
- First of all,/ Id like to explain the background /of this work. //During the past decade or two, /wireless sensor networks /have proceeded in terms of technology /and popularity. Many license free /low power radio systems have been developed and deployed /in various fields, /such as electric power meters, /water supply monitoring /and factory automation. //And so far, /most of these system had only data link layer protocol /and were used in a narrow area /and had limited range. //However, /with lower costs for the internet connectivity, /WSN/ are expected to be expanded and scaled to data centers. //The main issue of this work/ is how we can expand them. //The method is discussed in this presentation.
- Again, /I’d like to emphasize /that WSNs are required to connect data centers, /and that data which they generate /is transported to /and processed by these data centers. Between WSNs and data centers /is the backbone, /which connects them. //The internet is required, /in order to build an IoT backbone. //WSNs have only data link layer protocol, /and NO network layer. //In this situation, /how should WSNs /connect to the internet?
- Most attempts to scale WSNs /approach the issues from the IP side. //Basically /the Internet is composed of small IP sub-networks /which are interconnected with each other. //In other words, /the network which can be connected to the Internet /should implement the IP protocol. //Most WSN /have only a data link layer protocol, /NOT IP. /This means /that the IoT forces WSN/ to implement the IP function. /However, /we are wondering about the necessity of IP /to scale up WSNs /and concerned /about the increase /in the WSN terminal manufacturing costs.
- Before IoT became so popular, /WSN had existed. /WSNs /have been working well without the IP protocol /or the Internet. /This means /the IP is not essential /in order to collect data from WSNs, /and as you know, /big data processing /has nothing to do with any communication protocols. /Therefore /we propose a shared IP-VPN backbone /which bridges data link protocols /of WSNs.//This backbone/ means that WSN terminals and the application /need not to be conscious /of the IP network protocol.
- This chart shows /the positioning of our proposed approach. /But /I’ll skip this slide /and return /if I have a time. At the first step, most IoT service providers do a test for proof of concept in their labs. Small and inexpensive experiment test beds are used for this step. When the effectiveness is confirmed, they will proceed to the next step. In this step, they leave the labs and set up their equipment in a measured field such as a farm or factory, then connect to the data center. There are two possible ways in which this can be done: If they have enough funds and can expect customers to deploy a number of terminals from the start, they can step into full scale start startup. In which case, the cost of implementing the IP is not so important. Otherwise, another approach is available. They can use our proposed bridging backbone without additional development cost for applications and terminals. When their business is under way and promoted, then they can step into an IP stage. Thus we believe that our proposed technology is helpful fir small starters of IoT.
- Lets move on to the design goal of our backbone.//The most important point is the BRIDGING /instead of IP interconnecting /or gateway. /The WSN terminal /and the application /do not need to be modified /to connect to the IP network. /But, /because /non IP WSN cannot connect to the IP network directly, /some backbone edge is needed. /This means /additional development costs /should exist. /However /these costs will be incurred by the network service provider, /so the adaptation function /will be provided as a service. /This enables IoT CAPEX reduction /and a shortening /of the development period.
- Data link protocol bridging /is not a complicated technology. /The UART bridging scheme/ is shown in this slide. /An IP tunnel /is set up between two tunnel terminating software entities. /This software reads a UART device, /encapsulates the read data /and sends it to the peer through the tunnel. /When a data packet is received from the tunnel, /a data content is extracted from it /and written to a UART device. /Thus /two UART devices/ are virtually connected /and the data frames of UARTs /are transparently relayed /by the IP network./This is the principle/ of the bridging network. /We refer /to these tunnel terminators /as tunnel servers /and tunnel clients, /respectively, /and to this topology /as P2P, /point to point connection.
- However /such P2P topology /is hard to scale up. /Suppose /that multiple PANs /should be connected to a data center /via P2P bridging connection. /If an application server machine /has multiple serial ports, /it is possible /to aggregate the connections. //But /the application software /has to select the interface device /when it transmits a data frame. /To do that, /it has to know /what terminals are connected to an interface. /This is an extra function of the application, /and so modification of the application /is required. /However application modification /is a violation of our design goal. /Therefore/ we propose to add the routing function to our backbone network. /Thanks to this routing backbone, /the application does not need to be modified at all, /and multiple PANs are virtually consolidated /into a large scale LAN /from the point of view of the application.
- A routing function /needs key information to reference routing tables. /In most cases, /the key is a destination address for the data./Because our proposed backbone network /also has routing tables, /it needs to obtain address information, /so at least one MAC address /should be embedded in the routed data frame. /The position /and the length /of an embedded MAC address /varies depending on the sort of WSN radio system. /However if our backbone can retrieve it /by the WSN specification, /the WSN can be connected to our backbone.
- This chart shows the routing function of a tunnel server /which is located on the data center side./ The tunnel server /accepts IP tunnel set up requests /from the tunnel clients. /Each tunnel client, /located at a PAN, /notifies the tunnel server /of all MAC addresses of the terminals at that PAN. /This is the first step in this slide. /The tunnel server /forms a routing table /by using the notifications,<pause> step2. /It contains the MAC addresses /and the IP tunnel ids /such as sockets. /When the tunnel server receives a data frame from the application, /the MAC address /is extracted from the data frame, /and the table is searched for the MAC address. /Eventually /the data frame is sent to the tunnel shown in the search result.
- Another possibility/ is for the PAN side routing/ to be installed at the tunnel clients./This option is useful/ when a PAN is shared by multiple owners. /IoT is still developing,/ and many kinds of wireless terminals are appearing. /As an example, /let’s imagine your home network. /Many electric appliances /are beginning to connect /to their manufacturer’s data centers. /However /they won’t talk each other. /If each manufacturer /wants to access each appliance /through an individual access point, /your living room /will be packed full of many radio equipment./ So /it is much preferable/ for your single home Wi-Fi /to provide single access point, /which is shared by all manufacturers.
- An IP-VPN software, /such as IPsec may be useful , /but /IoT terminals generally have no visual display /and it is hard for general persons to configure VPN parameter. /This PAN side routing function /can solve this problem. /The tunnel client can create multiple IP tunnels /to different manufacturer’s data centers /and also forms a routing table /which contains the MAC addresses of the wireless terminals, /as well as the tunnel ids /of the terminal manufacturer. /When a data frame is received from the PAN, /the tunnel client /extracts the source MAC address /from the received data frame /and decides which tunnel to sent it to /by searching in the table. /In this slide, /two owners /share a single PAN. /The data frames transmitted by B3 /are sent only to the B’s data center.
- So far, /I have explained /that there are two kinds of routing function; /one at the tunnel server, /or /one at the tunnel clients. /The purposes are different. /The tunnel server routing /is for the PAN consolidation. /Multiple PANs /can be aggregated into a data center. /On the other hand, /the purpose of the tunnel client routing /is to share a single PAN between /multiple owners. /The routing table on tunnel servers /expresses where a certain terminal is placed, /and the routing table in tunnel clients /shows whom a certain terminal is owned by. /Therefore, /for a given terminal, /if the MAC address, /the owner id /and the PAN id /are specified by a manufacturer, /this allows the two routing tables /to be formed simultaneously.
- By combining these two routing functions, /we can build a mesh overlay network. /If a single physical PAN is partitioned into several logical segments, /for example dependent on appliance type, /and each segment is connected only to a particular application, /it would allow segments from more than one physical PAN /to be consolidated. /Multiple segments /located at distributed places /can be consolidated into a single virtual PAN. /This means that similar appliances /from separate PANs /could form a single virtual PAN. /This slide explains just the principle of the concept /for our proposed backbone. /However /several problems emerge /when we consider the implementation of this system.
- Firstly, /both tunnel clients /and tunnel servers /might lack the performance /to process the routing /and the tunnel termination. /But powerful CPUs cannot be expected /because of the customer dedicated equipment involved. /Next, we are concerned about security issues. /Because the tunnel clients and servers communicate directly, /user information, /such as peer IP addresses /could be exposed. /Finally, /The NAT firewall problem exists /when an application is located at guarded network. /The NAT drops the tunnel setup request from the out side.
- To solve these problems, /I introduced the switching server entity /to our architecture./Each tunnel server and client /creates a single tunnel to the switching server /and dedicates itself only to the encapsulation function. /The routing function is moved to the switching server. /The tunnel direction of tunnel servers is reversed, /so the NAT traversal becomes possible. /In addition, the switching server can reduce the configuration workload at tunnel clients. /A heavy installation process is impossible at the IoT field. /But in this architecture, /tunnel clients have only to know the IP address of the switching server.
- Furthermore, /we added SDN architecture to our system. /The SDN controller stores wireless terminals information; /MAC addresses, /Owner-IDs /and PAN-IDs, /and distributes the information to the switching server. /If the backbone is scaled up /and the switching server is divided into multiple entities, /the controller can lead the tunnel servers /and clients /to the appropriate switching server. /An owner of wireless terminals /can enter the terminal information through a portal site of the controller. /Thus, /there is no need for the end user to configure their IoT appliances at the end user premises.
- Finally, /I’d like to show you an example of the network service /which can be realized using our proposed backbone. /The bridging backbone /contains access points such as ZigBee coordinators. /When a small IoT product manufacturer starts /using ZigBee wireless terminals, /they first enter the MAC address, /owner-ID and /PAN-ID of the intended location /into the controller. /Then, /when the IoT appliance installed near the ZigBee PAN coordinator, /the PAN authenticates the registered MAC address /and allows the terminal to join. /As a result, /a computer at the owner headquarters /with the application and the tunnel server installed /can access the ZigBee terminal using only the MAC address.
- /So, /let me wrap up by giving you a summary and conclusion. /I compared /two types of method f/or connecting WSNs to the internet. /One method /imposes an IP stack /on wireless terminals and applications. /This method is, /so to speak, /an approach by IP. /On the other hand, /my proposed approach uses IP, /and the backbone bridges the data link protocols. /The big advantage of this /is that any modification, /such as implementation of IP and routing, /is no longer necessary. /This means /that the internet is no longer the key component of IoT. /It is merely a vessel /used to transport data /similar to modems in pre-internet times. /This doesn’t mean the end of the internet. /On contrary, /I suggest /that the internet can come to be used as transport infrastructure /for any protocols other than IP./ When we complete the evaluation of this system, /I hope to report it soon. /Thank you.