Networked Appliances

Reference

Service Portability of Networked Applicances by S. Moyer, D. Marples, S. Tsang, A. Ghosh

Introduction A network appliance (NA) is a dedicated

function consumer device containing a network processor.

Examples: Lamps, coffee makers, alarm clocks, phones The alarm clock should be able to adjust its

wake-up time based on your calendar, current weather and traffic conditions.

A refrigerator reports to a service station when it needs maintenance.

Introduction

Introduction

Introduction The end-user service is tied to the actual appliance

(e.g., refrigerator) and provides an enhancement to the functionality of the device.

However, the service may be separated from the physical appliance.

The appliance (alarm clock) is considered a convenient way to present or render the service for presentation.

The network infrastructure should enable service portability which allows the service to be rendered onto any suitable delivery platform.

The service that automatically starts your coffee maker should work whether you are at home or in a hotel room.

Network Appliances Today A multitude of devices and technologies

with limited interaction with each other and with the network.

Examples of some things we cannot do or can’t do with ease from a remote location: “Turn off all lamps at home” “Enable house alarms” Ask “What’s the kitchen temperature? Ask “Are all the doors locked” Ask “Is there milk in the fridge” “Let the plumber in”

View

View

The RGW provides secure access to the wide-area network (e.g., the Internet) and the ASP within that network.

At a minimum the RGW provides: Firewall capabilities Network Address Translation (NAT), NA IP interworking capabilities

Appliances that are IP capable may connect to the RGW through a home local area network (LAN).

Issues Naming and addressing

Location of the device and the physical device can vary; thus it must be possible to support both location and device independence.

Devices within the home need to be unambiguously named and their location identified from outside of it.

Can’t assume that all devices are IP addressable

Selection between multiple instances. Must be possible to browse for available NAs. Movement of NAs within a given domain and

across domains should not be restricted.

Issues Security considerations

NAs and their users must be authenticated and authorized when the NA first enters.

The entity trying to enter into the home needs to be unambiguously identified prior to permitting access.

Wide-Area Accessibility Should be possible for NAs to be accessible

from outside of the home.

Issues Protocol transparency and

independence It must be possible work with different in-

domain networking technologies transparently.

• Within a single home it is acceptable (not that we have much choice) that many different protocols are used for inter-device communication.

Must be lightweight Preferably connectionless protocol

Architecture Two types of network-based service

providers: Application service provider (ASP) and Network service provider (NSP).

The ASPs provides the platform for service logic execution.

The NSPs are responsible for the transport infrastructure from the ASP to the NA.

Example Architecture

Issues Sounds simple, but …. The home domain isn’t really going to allow just

anyone to access it. Most likely the network service provider will be the

entity that provides a ‘trusted’ Proxy between the applications provided by the ASPs and the home domain. Will the trusted proxy be the point where charges are applied?

What about portability? There are many different makers of the same type of appliance (e.g., lamp).

ASP services may vary based on the current geographical or logical location of the user at a given point in time e.g., the user may be on a business trip in a different city but wants the same alarm service.

IETF Initiative

The IETF is developing a network protocol for Networked Appliances based the Session Initiation Protocol (SIP).

SIP is a signalling protocol for Internet conferencing, telephony, events notification and instant messaging.

Address devices in SIP: Encode a hierarchical device naming scheme (e.g.,

SLP URL) to left of “@” sign in a To or From field. Encrypt encoded address to ensure privacy. Example: slp:/d=lamp,r=bedroom,u=stsang

IETF Initiative

SIP was initially created with call set-up in mind.

It is intended to establish a relationship or session between two endpoints

Important Methods: INVITE – Used to initiate a session with state DO – Indicates the action to be done at

destination. SUBSCRIBE & NOTIFY – Enables event

notification from and between networked appliances

Application Scenario (1)

The user wishes to turn on a lamp within their home from their office PC.

home.net is a NSP. co.com is a NSP.

Application Scenario (1)

Application Scenario (1)

The SIP messages for the remote control are shown below:

(1) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp <command><turn>On</turn></command>

This can be sent from any PC in the company. This is routed to a SIP server on co.com

Application Scenario (1)(2) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via SIP/2.0/UDP co.com Via SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp <command><turn>On</turn></command>

The co.com proxy (a SIP server) does lookup in DNS for [d=lamp,r=bedroom,u=stanm]@home.net for the SIP server for the destination domain. It gets the value of home.net.

Application Scenario (1)(3) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via SIP/2.0/UDP home.net Via SIP/2.0/UDP co.com Via SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp <command><turn>On</turn></command>

The user name is unique within the domain of the SIP server on home.net; This is sent to stan.home.net which is able to deal with resolving the network address to the device address and deal with firewall issues.

Application Scenario (1)(4) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via SIP/2.0/UDP stan.home.net Via SIP/2.0/UDP home.net Via SIP/2.0/UDP co.com Via SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp <command><turn>On</turn></command>

This is received by an appliance controller for a lamp.

Application Scenario (2)

Now let us deal with the case that the lamp from stan.home.net has temporarily been moved to simon.home.net

To accommodate the change, a re-direction is added to the home.net proxy.

The SIP messages for this scenario are shown now shown.

The first two SIP messages are as before.

Application Scenario (2)

Application Scenario (2)

The third SIP message is as follows:

(3) DO sip:[d=lamp,r=bedroom,u=stanm]@simon.home.net SIP/2.0 From: sip:stan@co.com To: sip:[d=lamp,r=bedroom,u=stanm]@home.net Via SIP/2.0/UDP home.net Via SIP/2.0/UDP co.com Via SIP/2.0/UDP anypc.co.com Content-function: render Content-type: application/dmp <command><turn>On</turn></command>

The home.net proxy did a look-up and finds that Stan’s bedroom lamp is now in Simon’s spare room.

Application Scenario (3) Stan is riding with Dave in Dave’s car and

remembers that he was expecting a service person to come and fix the dishwasher and he does not have his web phone.

He asks to borrow Dave’s phone and sends a message to his service provider to notify him if someone “rings” the doorbell.

When the service person “rings” the doorbell (and authenticates themselves with their ID badge), a message is sent to Dave’s web phone for Stan that the service person is at the front door.

Application Scenario (3)

Application Scenario (3)

The SIP messages needed are below:

(1) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp <event>ring</event>

Application Scenario (3)

(2) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp <event>ring</event>

Application Scenario (3)

(3) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp <event>ring</event>

Application Scenario (3)

(4) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0 From: sip:stanm@dave.mobile.net To: sip:[door,r=front,u=stanm]@home.net Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP mobile.net Via: SIP/2.0/UDP dave.mobile.net Contact: sip:stanm@dave.mobile.net Content-type: application/dmp <event>ring</event>

Application Scenario (3)

(5) Door Bell Rings; Credentials established(6) NOTIFY stanm@dave.mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: ua.stan.home.net Contact: sip:stanm@dave.mobile.net <event>ring</event> <identity>Maytag Repairman</identity>

Application Scenario (3)

(7) NOTIFY stanm@dave.mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: stan.home.net Via: ua.stan.home.net Contact: sip:stanm@dave.mobile.net <event>ring</event> <identity>Maytag Repairman</identity>

Application Scenario (3)

(8) NOTIFY stanm@dave.mobile.net SIP/2.0 From: sip:[d=door,r=front,u=stanm]@home.net To: stanm@dave.mobile.net Via: mobile.net Via: stan.home.net Via: ua.stan.home.net Contact: sip:stanm@dave.mobile.net <event>ring</event> <identity>Maytag Repairman</identity>

Application Scenario (3)

The user is alerted and decides to unlock the door.

A DO message to unlock the door is sent along the same route as the SUBSCRIBE message sent earlier.

Application Scenario (4)

A network-based alarm clock service attempts to deliver a wake-up alert and announcement to the user.

Assume that the user has previously configured the service to be delivered to him/her.

The `alarm clock’ used to deliver the service does not have to be a physical clock, but simply a device, discovered by the service, capable of receiving an audio stream.

Application Scenario (4)

SIP is used to set-up the audio session. The network-based alarm clock service

provider (called alarmclock.net) establishes the audio session and plays the audio announcement(s) at the appropriate wake-up time which is configured through the user’s personal calendar and adjusted based on current traffic and weather conditions.

Note the difference between this scenario and the others: The others were session-less. This is not.

Application Scenario (4)

Application Scenario (4)

INVITE sip: [d=alarmclock,r=bedroom]@home.net SIP 2.0From: sip.announcement@alarmclock.com To: sip[d=lamp,r=bedroom]@stan.home.netContent-type: application/sdp[SDP Parameters for uni-directional RTP stream]

Messages 2 and 3 are basically the same with the additional routing information.

A response is then returned to the alarm clock service provider with the alarm clock’s RTP parameters and an audio stream is initiated.

Application Scenario (4)

Let’s say that Stan is staying over at a friend’s house and would like the alarm clock service to wake them up there.

Stan doesn’t want to bring his clock. A redirection is done which is handled

by REGISTER messages.

Security Considerations Authentication of all SIP messages is needed. There is a need for “trusted” proxies. Network

Service Providers may end up being these “trusted” proxies.

How do we control access? Currently, SIP requires some form of public-key

technology. This makes sense for Internet phones since communication can potentially occur between any two parties.

Many believe that in the case of remote access to NAs within the home that shared secret keys are better. Here communication can’t just occur between any two parties.

Do we encrypt end-to-end or hop-by-hop? SIP allows both.

Initiatives

There are lots of initiatives that focus on making networked appliances successful. SIP is specifically focussed on being a network protocol. Other initiatives include: Open Services Gateway Initiative (OSGi) –

Middleware for delivering and managing multiple applications.

UPnP – in-home inter-device communication HAVi for in-home inter-device communication SLP – Location and identification of services Salutation – Location and identification of services