Service Centric Networking Architecture for Smart Homes

Home network has driven a huge amount of attentions from both researchers and industries. While home network grows in complexity as more smart appliances, sensor and network devices join in, we would like to use SCN to fit into home network's scenario which has plenty of control information as well as data information.

Based on a state-of-the-art study, we propose following homenet topology as a basic model. Homenet Gateway has the ability to pre-process and aggregation data and then sending to those interested devices. Homenet gateway will hold PIT, FIB and CS tables for sending corresponding message to region routers, consumers and outside networks. Region routers are located at different regions which could be different rooms or floors. Normally one region will have one sub controller as long as the total number of devices is under the capacity of the region router. Region routers only perform the role of collecting information and then send them all to the homenet gateway for further processing. They will have PIT, FIB and CS tables for sending corresponding message to devices.

+--------+ +--------+ | Device | | Device | +--------+ +--------+ \ / \ / +----------+ +--------+ | Region | | End | | Router_1 | | User | +----------+ +--------+ \ | \ Firewall | +----------+ +-----------+ +-----------+ +--------+ | Region | | Home | || | | | Device |------| Router_2 |-------| Gateway |-----||-----| ISP | +--------+ +----------+ +-----------+ || | | / | +-----------+ / | +----------+ +------+ | Region | | End | | Router_3 | | User | +----------+ +------+ / \ / \ +--------+ +--------+ | Device | | Device | +--------+ +--------+ Devices (sensors, applications, users, actuator and so on) are connected to their nearest region routers. Some of them, like sensors and users, will produce real time data packet and push them to their region routers. Some of the devices, such as applications and users which have special concern, will register their interests to region routers and home gateway. The rest kinds of end devices, like furniture and electric appliances, will wait for commands to adjust their behaviours. An end device can perform several roles, take a user as an example, the user can push heart beat rate as well as ask for room temperature information and then send control information to manipulate air condition. ISP gateway: The homenet gateway connects to the Internet service provider (ISP) gateway, through which the homnet can connect to application and end users, who have been authorized, at outside internet. Devices that generate real time data, such as smoke sensor and temperature sensor, will be configured to periodically upload their data to a neighbouring region router. At the same time, those sensors can also respond to an interest massage to report their current readings. Other devices that generate stream content, such as surveillance, will store stream data with sequence numbers and waiting for command from end user or application. A client or application sends interests messages for services to be invoked and the results from service execution or state transitions are returned in data packet.

In smart home network scenario, data is not just retrieved, but can be processed before being presented to the user. Also end users and applications can deliver command content. So we propose to extent names not only for content but also for services to be invoked. Information generated inside a smart home has finite kinds of types. So it is sensible to tailor the naming strategy into the following structure: 'Access scope/service type/device scope/service API/' In a service centric network, services may be restricted to only local access and/or set for global access through the Internet. Also, a service may have strict access control, and temporal or physical restrictions in terms of where it can accessed in the smart home network. So the first segment 'access scope' indicates who can access this service. The second level 'service type' shows the type of data and it can be instant content, stream content and command content. The third level 'device scope' can accurately locate device or a group of devices that provide this service. The final scope 'service API' identifies the functional primitives and attributes used to interact with the service which can be upload(), switch_on(), mode_1() and so on. Following are examples of naming messages. In order to collect all the smoke condition in the house, Fire Alarm broadcasts an instant content interest packet to the network with the name of '/smarthome/instance/smoke/' Smart home Application wants to get access to all the cameras on the second floor, a stream content interest is broadcasted to Router B with the name of '/smarthome/stream/camera/2F' Smart home Application wants to send a command to turn off all the lights on the second floor '/smarthome/command/light/2F/set_state{OFF}';

In this architecture, a router maintains a pending interest table (PIT) for outstanding forwarded requests, which enables request aggregation, to make sure that a router would normally not forward a second interest for a specific content in a particular time span. The PIT maintains state for all interests and maps them to MAC addresses, which are used as unique node identifiers. Data is then routed back on the reverse request path using this state. Service centric network architecture also supports on-path caching and name-based security. The novelty of this architecture's routing is reflected in the following aspects: (1) Content pushing is more important than content pulling in some smart home scenarios, such as periodically uploading humidity data collected by sensors or flooding emergency messages triggered by fire alarms. These contents must be quickly disseminated toward the intended locations even though there is no request. Assuming that some sensors lack of storage capacity, the data collected by sensors are sent to the nearest router periodically via wire or wireless channel to leverage the large storage space of routers. (2) A consumer uses interest packet to request content from the network. Following the naming scheme, the consumer declares the service type in the name of the interest. Interest packet is broadcasted to all the neighbouring routers. Different service types do not influence the maintenance of PIT table and the forwarding scheme, so the architecture has a good compatibility with other information centric architectures. (3) To solve the problem of control message delivering, a novel mechanism is introduced. A command message generated by a controller is seen as an interest packet, known as command content interest. The name of the interest is the device name which intends to be controlled. The content requested by the controller is the state of the device after the command is successfully delivered. The command content interest follows the same procedure as an ordinary interest to realize the delivery of a command. The command content can also be seen as the acknowledgement of a command message.

Three scenarios are discussed to demonstrate the feature of SCN when handling different services.

+----------+ +-------------+ | Smoke | | Smart home | | Sensor B | | APP | +----------+ +-------------+ \ / \ (7)/(6) \ / +----------+ (3) +----------+ +----------+ | Router A |-------| Router B |--------| Home | | [CS] | (4) | [CS] | | Gateway | +----------+ +----------+ +----------+ / \ (1)/ (5)\(2) / \ +----------+ +----------+ | Smoke | | Fire | | Sensor A | | Alarm | +----------+ +----------+ STEP 1: Smoke Sensor A periodically uploads the instant smoke data to its neighbouring router to leverage the large storage space of Router A; STEP 2: In order to collect all the smoke condition in the house, Fire Alarm broadcasts an instant content interest packet to the network with the name of '/smarthome/instance/smoke/'; STEP 3: On receiving the interest packet from Fire Alarm, Router B updates its PIT table and forwards it to Router A; STEP 4 and 5: After Router A receives the interest packet from Router B, the instant smoke content is forwarded to Router B and Fire Alarm using the backward route; STEP 6 and 7: Suppose that Smart home APP want to request all the instant monitoring data in the house, an interest packet is sent to Router B with the name of '/smarthome/instance/'. The smoke content data uploaded by Smoke Sensor A is forwarded to APP directly from Router B, thanks to the caching scheme of SCN.

+----------+ +-------------+ | Camera A | | Smart home | | (Floor1) | | APP | +----------+ +-------------+ \ / \ (6)/(1) \ / +----------+ (2) +----------+ +----------+ | Router A |-------| Router B |--------| Home | | [CS] | (5) | [CS] | | Gateway | +----------+ +----------+ +----------+ / (4)/(3) / +----------+ | Camera B | | (Floor2) | +----------+ STEP 1: Smart home Application wants to get access to all the cameras on the second floor, a stream content interest is broadcasted to Router B with the name of '/smarthome/stream/camera/2F'; STEP 2: On receiving the interest packet, Router B updates its PIT table and forwards it to Router A; STEP 3 and 4: On receiving the interest packet, Camera B send video stream content to Router with the name of '/smarthome/stream/camera/2F/caremaB' and an increasing sequence number; STEP 5 and 6: The stream content is forwarded to Smart home Application using the backward route and is saved by Router A and Router B.

+----------+ +-------------+ | Light A | | Smart home | | (Floor1) | | APP | +----------+ +-------------+ \ / \ (6)/(1) \ / +----------+ (2) +----------+ +----------+ | Router A |-------| Router B |--------| Home | | [CS] | (5) | [CS] | | Gateway | +----------+ +----------+ +----------+ / \ (4)/(3) (8)\(7) / \ +----------+ +----------+ | Light B | | Central | | (Floor2) | | Monitor | +----------+ +----------+ STEP 1: Smart home Application wants to send a command (eg. turn off) to all the lights on the second floor, a command content interest is broadcasted to Router B with the name of '/smarthome/command/light/2F/' and with the service API's value of 'set_state{OFF}'; STEP 2: On receiving the interest packet, Router B updates its PIT table and forwards it to Router A; STEP 3: On receiving the interest packet, Light B changes its state into OFF and return a content packet with the name of '/smarthome/command/light/2F/lightB' and with the service API's value of state{OFF}'; STEP 4, 5 and 6: The content packet is forwarded to Smart home Application using the backward route and is saved by Router A and B; STEP 7 and 8: If the Central Monitor want to know the state of all the lights in the house, an interest packet is broadcasted with the name of '/smarthome/command/light/'. The state of Light B is forwarded to Central Monitor directly from Router B, thanks to the caching scheme of SCN.

Mobility: Sensor or end user move around (step between different networks or move between different regions), they may need to connect to different region routers. Mobility support for both service producers and consumers is required to ensure best connectivity at all times. This includes nomadic movement, seamless mobility to handle real-time applications, and vertical handovers between different access networks as residents move in and out of their region premise. Scalability: One of the benefits for applying SCN rather than IP is that SCN could support as many devices as needed, while IPV4 or IPV6 could run out of available addresses. Security: A new device joins in (public key encrypt, private key decrypt to guarantee authority), information or data generated inside the smart home should keep confidential and private, and accessible through strict access control; it is safer to use SCN than IP architecture.