IEEE ICC ‘16 Dynamic M2M Device Attachment and Redirection in Virtual Home Gateway Environments Apostolos Papageorgiou, NEC Labs Europe Roberto Bifulco, NEC Labs Europe Ernoe Kovacs, NEC Labs Europe Hans-Joerg Kolbe, Deutsche Telekom AG

Background: Virtual Home Gateway USB Ethernet WiFi ZigBee Bluetooth UPnP …… Operator‘s Backend System HGW Network Protocol M2M devices M2M devices’ drivers The complexity of the Home Gateway (HGW) is an issue More expensive (CAPEX) More difficult to operate (OPEX) More difficult to troubleshoot (OPEX) More components can fail (OPEX) More components need update (OPEX)

Background: Virtual Home Gateway USB Ethernet WiFi ZigBee Bluetooth UPnP …… Operator‘s Backend System HGW Network Protocol M2M devices M2M devices’ drivers USB Ethernet WiFi ZigBee Bluetooth UPnP …… Operator‘s Backend System Bridged Residential Gateway Network Protocol vGW Minimalized M2M Anchor Protocol Virtualization M2M devices M2M devices’ drivers

Challenges and Opportunities Device attachment The M2M anchor does not know the device Drivers/Operating system compatibility issues Protocol virtualization The selection of the backend server is pre-configured The selection of the backend server is static The device’s communication flow cannot be easily identified at the network level Several “servers” to handle one home’s devices Decoupling the physical attachment point from the logical mounting point Support scalability

Virtualized access to M2M devices M2M anchor S/W Incl.: Virtualization S/W, e.g., USB virt. client M2M server config Device-to-port mapper Network Controller 1 ... SDN M2M 2 3 10.0.0.1 Virtualized access, e.g., with USB virtualization M2M Access Manager vGW vGW ..... M2M Srv. A Minimalized M2M Anchor 10.0.0.2 M2M Access Manager vGW vGW M2M Srv. B ...... ..... ............................................. Network infr., e.g., OpenFlow switches 10.0.0.n M2M Access Manager Minimalized M2M Anchor vGW vGW M2M Srv. N ..... Servers or VMs

High-level process for mounting M2M devices M2M anchor NW switch NW controller M2M servers Generate constant port number for this device 1 Setup virtualized connection based on the M2M anchor‘s „server configuration“ 2 1 Inform upon failure Decide If able to mount 2 2 Find capable server / VM Add re-direction rule 3 (Device traffic) (Possibly redirected device traffic) 3 (Device traffic) (Possibly redirected device traffic) (Device traffic) (Possibly redirected device traffic)

1. M2M anchor „device attachment logic“ This source port is maintained for any communication originated from the device and destined to the M2M server; Different devices MUST have different source port numbers. M2M anchor S/W Incl.: Virtualization S/W, e.g., USB virt. client M2M server config Device-to-port mapper M2M Devices X Device-to-port mapper Y Minimalized M2M Anchor Z Device Src Port X (USB) 4550 Y (Eth) 5001 Z (USB) 4551 ... Virt. technology Port range USB 4000-4999 Ethernet 5000-5999 ... Enables the identification of the network flows related to a device without requiring DPI (Deep Packet Inspection) providing additional „lightweight“ info about its virtualization technology

2. Troubleshooting & negotiation of device mounting If an M2M server fails to mount a device that was just plugged in, the M2M Access Manager is informed The M2M access manager triggers an M2M server selection logic in the network controller (implicit information about the virtualization technology is provided via the port number) The selection logic selects a different M2M server according to information provided and based on additional constraints (e.g., server load, type, etc.) The selection decision is then transferred to the SDN controller Server info table USB virt. Ethernet virt. ... virt. Load / Stats Drivers info 10.X.X.1 ✘ ✔ ... 10.X.X.2 3 I cannot handle incoming packets from X.X.X.X:4551 Network Controller ... SDN M2M 4 2 10.X.X.1 Attempt to mount newly attached device M2M Access Manager 1 vGW vGW ..... The software stack of the M2M server informs directly the network about its ability to handle the connection from a given device

3. SDN-based configuration of M2M traffic Network Controller The SDN controller instructs the switch to forward any packet destined to the M2M server address to an actual M2M server (Translating from the IP address configured in the M2M anchor into the M2M server real IP address) The SDN rule redirects the flows related to a device (identified using the SRC Port) to the newly selected M2M server ... SDN SRC IP DST IP SRC Port DST port Action Any 1.1.1.1 1111 - Set DST IP = 10.0.0.1 - Fw-to-M2M srv. B Port M2M Anchor 4550 - Set DST IP = 10.0.0.2 The network is able to selectively redirect a network flow related to a given device attached to a given M2M Anchor

Alternatives No one-size-fits-all solution Usually a trade-off between flexibility/costs/complexity

Conclusion A solution for attaching M2M devices in a Virtual Home Gateway environment Virtual Home Gateways are starting to be deployed this year More relevant in future with IoT growth No one-size-fits-all solution But if an SDN network is available, many advantages can be combined And now… what about applications?