AUTOHAN Core Services Whiter Paper One - Feb 2000
DJ Greaves, A Blackwell, DL Gordon, U Saif, A McNeil, SB Suh - Third Draft
Core Services: AbstractIn Autohan we are trying to solve the basic problems of home control, where a multitude of devices must interact with each other and the residents in a sensible manner. Our focus has been on designing an architecture, but now we are working on the application coding model and user interfaces. Autohan is split into a core services part and a user interface part. This document covers core services only. In the user interface part, we are looking at seemless migration from existing paradigms, such as IR handheld controllers and real-time control, to a situation where the user can write programs using voice and gesture input and the Media Cubes. There is a little more info on the user interface side here . ArchitectureA home network has a low-level architecure, that provides networking, naming, addressing, maintenance and directory services. In AutoHan, we have invented one of these, based on IP, GENA, HTTP and HTML. This allows basic web browser access to a home for display and simple control, as in Upnp. We are now working on the high-level application coding model and user interfaces. The glue layer between the two levels is device modelling. Our approach to this is to expect well known strings, such as `frontdoorbell' and `livingroom' to be properly bound by the lower level so that higher level software can be run. Low-level ArchitectureArchitectures for the lower-levels of home networks and home control have been proposed in the past and four significant potential system components today are: Our lower-layer work includes and builds on many of the elements that have been developed in these previous home network control systems. We borrow from them where needed which helps with compatibility. Our low-level architecture includes most of Upnp. There is a white paper by Saif that explains our approach ["Internet Access to the Home Area Network" ask us for a preprint]. It almost goes without saying that we are not tied to a specific physical layer, such as 1394 and we do have full support for Internet protocols. High-level ArchitectureOur high-level architecture facilitates real-time control of the home by the user and also programming of the home by the user. We are looking at how the user interface for these two activities can hide the normal distinction found in computing between writing a program and running it. Our architecture also solves interaction issues between conflicting requests, such as the desire to mute the TV but not to mute the baby monitor or between a command that spends money on pay-per-view and a rule which restricts expenditure from a given piggy bank.Autohan IntroductionAutohan is the name for our reference implementation of the home area network. An `Autohan' consists of all Autohan complient devices connected to a multicast group that spans the home. The system includes three levels which together provide a full network and system architecture to allow home networking systems. All of the various physical layers inside the home, from HomePNA to HomeRF, are integrated by our bottom layer into a single network. This network supports: unreliable ASCII datagram multicast, reliable ASCII datagram exchange and normal connection-oriented and connectionless network services with or without QoS. An autohan entity must send XML as ASCII or BXML over UDP/IP, TCP/IP, MAC-layer frames or IPv6 negighbour discovery protocol. This does not rule out dumb devices, as exemplified by our Warren Project, since a software proxy for the dumb devices exists. The cost of implemenetation of at least one of these link layers will be very low in the future. For instance, XML over UDP/IP can be implemented on a low-end single chip processor, such as a PIC device , so is not a barrier for future low-cost, home devices. Indeed, adding 100 kilobytes of ROM code is no longer seen as a barrier even for very low-cost devices, provided the software never needs upgrading. Autohan is designed to work with and without an always-on connection to the outside world or Internet. Also, a dedicated control node is not needed to start with. The Autohan architecture uses the concept of a home containing a number of networked devices. The edges of the home are delimited by the access network devices. If there are two or more disconnected sub-networks inside the home, there will be two or more Autohans. Autohan networks consist of the following physical entities:
When a sever is not the active home server, it may still be providing execution resources for a soft function. An example is a set-top box, which might contain hardware to assist with a video decompression application. This application can still run in the STB and is Although the full Autohan approach includes the home server , the architecture provides effortless migration from installations without home servers. A simple installation will have no home server and everything is operated out of ROM in the consumer devices that are present: no set-up information need be stored in non-volatile memory. As the network grows, certain consumer devices may be added which can provide a home server, and some of these may be able to become the master, in which case one of those be elected to act as the active home server. As mentioned, advanced installations will have a dedicated box to be a home server. This box could be a PC, but PCs are not ideal on noise, power or reliability grounds, so the box is more likely resemble a digital set top box. The home server may also be a remote service provided over the access network where `always-on' service is available, such as with xDSL. Autohan is designed to be robust and easy to use. It is also designed for low-entry effort for manufacturers of consumer goods. Low-entry effort is achieved owing to less than 64 Kbytes of code in small, non-dumb devices and by removing the strict need for non-volatile storage and unique identifiers in such devices. The Autohan protocols are built on IP using UPnP and HomePnP with XML. There are references to these terms at the end of this document and more detail in the body. Application code in Autohan is designed to be mobile. This means it can run on any device in the home which has the capability and capacity. When a server or host device is switched off, applications which are still needed migrate to another suitable host. Most modern devices have a soft off switch which invokes a standby mode, so software has the information and power to migrate. Devices with hard on/off are also supportable, see missing link. Autohan Structure and LayersAs mentioned, Autohan has three layers to its structure. It also has a common modelling plane. The three layers to Autohan are:
Device modelling and naming are critical functions in the home area network. We have a separate modelling plane which runs through all three layers to handle these functions. This plane uses an XML encoding of the system started by cebus.org for HomePnP, but including much of the work done in HAVi. Network Resource LayerThe Network Resource Layer contains power management, physical-layer networks, operations and maintenance, network layer protocols and lowest-level registration and name-serving functions. It provides all of the basic operations to allow connectionless datagram and streams with QoS to flow between peers. It provides registration functions for devices and has a management interface which exports information about the registrary and network toplogy and status. Where ATM networks or other connection-oriented (CO) network are used in the home, the resource layer instantiates a LAN emulation service to provide connectionless services. This is not ATMF LANE since that is far too complicated and cannot be used as a start of day service without ATM signalling in place. Autohan LAN emulation uses pre-assigned VCIs which the switches guarantee to have been set up to provide the appropriate service. A separate document describes this [document is written but link not installed]. An example of a low-cost ATM network for the home is Warren. At the moment, the important high-performance physical layer networks for the home are HomeRF, Power Line modulation from Enikia and Intellon, HomePNA2.0 and various technologies on new media, especially 10baseT and P1394. Bluetooth and infrared will be important short link technolgies. Gateways to low-rate, older home networks, including CEBus, Echelon Lonworks and X1.0 are also needed. An aim of the Network Resource Layer is to be as slim and self-configuring as possible. This involves collapsing all of the issues and problems found in conventional LANs with WAN access into a problem which can be handled by the naive home user. The UPnP and SSDP protocols have been designed for this and we use them. Application Execution LayerThe application execution layer provides services for software applications to run and store their persistent data. Applications in Autohan are pieces of software code which do not mind where they are executed provided they have sufficient connectivity to the physical devices involved. Application software divides itself into two classes:
Persistent information, such as files and CMOS RAM setups, remains available from one run of an application program to another and locks may be needed for simultaneous access from multiple instantiations of the application code. This information must be retrieved using a name (or handle) and our modelling plane provides suitable naming conventions. Applications need to express the bandwidth they need for access to persistent store, since this will affect where they run. Clearly, in most cases to start with, a Video Recorder application will normally run on the processor in Video Recoder which is also where the tape or disk is that is doing the recording. However, what we are doing is adding a little complexity at this point to allow greater flexibility in the future. Perhaps in the future, people will keep their video information wihe the same agency that they use to keep their current bank account: afterall, both are data storage buros (fix spelling). Application software is divided in another direction into a further two classes:
In Autohan, actual applications must either be written in a portable programming language such as CAL, Javascript or HTML, for which an interpreter is available, or else they are written in a non-portable form, embedded in the ROM of the consumer device which supports them. Actual applications can run automatically when a device is switched on or can be started by other applications. Servers may export the services of their interpreters, and other similar such services that they may contain, for the use of other general applications. The Autohan brokering functions facilitate this export and the delivery of code to be run by the exported interpreter. The interpreters which we are implementing are:
Devices may be entirely soft, with no physical hardware, yet they are still a device in the Autohan architecture. There are many examples of such purely soft devices to be found where data needs to be converted from one form to another. Such examples are modems, set-top-boxes, baby monitoring, voice recognition, encryption. Another example which does not merely convert data, but which instead needs access to secure, persistent storage, is an electronic piggy bank. Application Authoring and Configuration LayerThe Autohan architecture supports instantiation of application code in four main forms, but each of these has variants. The forms are:
Device and World Modelling PlaneThe modelling plane allows a device or other entity to describe itself and for names and other information to be allocated and associated with an entity. A device may be something like a CD player. Other entities might be people, recordings, radio channels, e-cash accounts and so on. In semantic terms, a heirarchic description of devices is used, but a flat XML syntax is used. A heirarchic description allows a device to describe itself as a composition of smaller devices. For instance, a TV set can consist of the following items: a colour screen, a UHF RF front end, a stereo audio amplifier, a NiCAM decoder, a teletext decoder and an infra-red receiver. The detailed specifications of these components can then be described in turn. Note that a TV set which supports closed captioning and graphical readout of control settings may include at least one frame store, which is a component that it would be useful to have access to over the network. A TV set which supports picture-in-picture or MPEG decoding will have multiple instances and varients of several of the components. Home Networking Reference Model |
|
One of the Autohan protocols elects the active autohan home server which performs CAC for the devices and network links. Devices and networks which perform their own CAC functions are consulted by the active home server before use and so their CAC functions operate as normal. Devices which do not provide CAC, such as Ethernet or Java RMI have this service provided by the active home server. Interpreters for actual applications are spawned using CGI (common gateway interface). The interpreters are spawned as a result of starting of an application or arrival of a mobile application needing that interpeter. The number of applications that an instance of an interpreter can support depends on the interpreter. Even if an interpreter can support multiple applications, most interpreters today do not provide sufficient isolation of processing demands between clients for effective processing time resource allocation, so it is necessary for applications to be grouped on to interpeter instances according to similarity of QoS requirements. Autohan Device System SoftwareThe following protocol stack is found in Autohan Devices. |
|
In these two pictures, the layers have been labled with the OSI layer numbers. The Autohan layer numbers need to be added. Tangible Abstract Events: The Eighty EventsThe home user will become acustomed to using events to control the home. Events will become tangible and it is then useful to introduce the concept of a small set of named abstract events. To make these less abstract in the first instance, we chose nine of them and map them to the numbers 80 to 89 when dialed on any telephone in the home (we assume you will dial 9 for an outside line in the home of the future). Keying one of these two digit sequences immediately causes the event to happen. The facility is aslo provided when dialing in from outside on a DTMF phone, although an authentication code might need to be prefixed in the longer term. We call these the eighty events. The role of the eighty events is to be totally soft and user-programmable on per-home basis. For instance, a user might use them for heating control, video-recording, door unlocking or lighting control. Generic FunctionsThere are a number of devices that we expect to find in all Autohans. These are known as generics. They have well-known textual names and interfaces. Most of them are virtual devices and the ones which could be physical, such as `front_door_bell' will typically be virtual: for instance, we typically need a way of effectively pressing the door bell, without going outside, to test an application. Generic Function: Clock TimerGeneric Function: PiggybankGeneric Function: RegisteryGeneric Function: Authentication ServerGeneric Function: Front Door BellGeneric Function: Global EventGeneric Function: DTMF and Voice RecogniserTelephone Exchange ExampleThe telephone exchange is being implemented in the event language using Warren telephones as the main peripherals and with voice messaging on the Media Server. The event system enables a telephone exchange with voice mail to be designed. The system is highly flexible and extensible since we can add a physical Warren phone or web page phone or new features while the system is running and calls are in progress. We also demonstrate an authenticated enterphone application which uses the same phone instruments at the same time, authenticated dial-out and charging mechanisms. Telephone's and other devices which wish to call or be callable from the exchange must contact the <telephone-manager> device and register their interface and identity. The telephone may not export all of its buttons, for instance, since it might register some of them with a totally different application gateway, for example, for local lighting control or door release in the enterphone. In the case of our Warren Telephones, which are dumb, the fact that a new phone has been connected is detected by the Warren controller which instantiates a proxy on a local machine. This proxy then registers with the Autohan registery and thence the <telephone-manager> gateway. The <telephone-manager> gateway could be created after some phones have already registered in the Autohan registery. This is no problem since applications perform a search for existing devices when they start. A Warren Telephone registers itself with the telephone manager by sending the following string: telephone-manager-register timeout=100 model=warrenphone_v1.1 number=3455 The Warren Telephone could generate individual events for the main event engine on each key press or else a separate scrpt can be used to marshall the phone button presses into a number or else the proxy could do it. We chose to use the subsidiary script approach. Our basic telephone exchange uses for each phone the state machine, shown here, where the states are idle, dialtone, no-credit, ringing-remote, connected, engaged, other-party-disconnected, ringing-locally. This state machine intrinsicly supports multi-party calls using the model where a conference call is given its own dial-in number. The machine needs extension to support voice messaging. The telephone exchange is an Autohan class three application, in that it was written by experts, downloaded and run on a home server. It was written as a state chart which was compiled into individual event transitions by our event compiler. We give an example where the user can latch on to these transitions to trigger muting of the TV aduio stream. Modifications of the downloaded software by the user can be done by redirecting the I/O to a particular phone through a user-created proxy or by modifying the rules themselves. We present both alternatives and are working out which is best. Owing to the flexibility of our architecture, dialing using voice recognition or to a destination flashed up during a television program are both easy to implement. Event SubsystemThere are many sources of events in a home. Catflap's, doorbell's and IR keypads all provide events from the movement of animals. Other events come from timers, radio data systems (RDS) and over the access networks. Most of the control functions which are needed can be chunked into large, atomic commands, such as record channel 3 for 25 minutes at LP resolution on mediaserver 2 against storage quota 71. Most of the remaining control functions are similar, but have distinct start and stop commands, such as the creation of a voice channel between phones 12 and 4 and the tearing it down. This leads us directly to consider a programming language for the home where events are the first-class citizens. Event rules written in an event algebra detect patterns of events and trigger other events. Variables are still needed, for recording amounts and quotas, but these can be accessed by sending events to objects which credit and debit the quotas. A rule-based language has many advantages for the home. Firstly, all of the rules can be stored in one system so that they can be checked for conflicts. Secondly, rules might be more easy to understand by users than imperative programs. Thirdly, untrained users can generate rules rather directly using a number of uer interface devices. Media Server Example
An autohan device is a hardware box. It may host a variety of applications, called capabilities. We need to change our nomenclature to be inline with Upnp. This initial definition needs to be extended to support generic processing boxes who can load application code from elsewhere. The media server is bundled with other application on a hardware platform that consists of disk, processor, ROM and network interface. There is no user interface, except a power on LED. Each application on the platform and the platform itself register with the registery. The media server handles streams as well as asynchronous events, but we control the streams by implementing a synchronous RPC system over the asynchronous event mechanism. The media server exports is description in XML as follows:
<device>
<model> "Prototype Linux-based Media Server" </model>
<version> 1.1 </version>
<manufacturer> "University of Cambridge" </manufacturer>
<uid> 0x234834827 </uid>
<capabilities>
<HAVi_VCR> HAVi-VCR0 HAVi-VCR1 HAVi-VCR2 HAVi-VCR3 </HAVi_VCR>
<Autohan_media_server> autohan_media_server </Autohan_media_server>
<Autohan_file_server> autohan_file_server </Autohan_file_server>
... transcoder ...
</capabilities>
<SourceStreams>
<Stream>
<StreamType>Audio</StreamType>
<Occurence>Continuous</Occurence>
</Stream>
</SourceStreams>
<SinkStreams>
<Stream>
<StreamType>Audio</StreamType>
<Occurence>Continuous</Occurence>
</Stream>
</SinkStreams>
<Audio>
<Encoding>PCM_16-bit_linear_stereo</Encoding>
<SampleRate>44100</SampleRate>
</Audio>
</device>
We would envisage that transcoding is also a capability of the device to enable it to replay in a different format from that used in recording. We would need to establish an instance of a transcoder and a replay connection that goes through the transcoder. Important aspects of the design of a media server are naming of files, access permissions and content self-destruction. In all of these respects, the media server should be easy to use in the sense that no manual intervention is ever needed.
The capability describes its API.
<server>
<service> Autohan_media_server </service>
<hostuid> 0x234834827 </hostuid>
<capabilities>
ascii_text_directory
record_atm_stream_aal0_3675
replay_atm_stream_aal0_3675
</capabilities>
</server>
Tuner ExampleThe FM tuner describes itself as follows: <Device> <Model>Tuner</Model> <ID>Warren_0x00C00903</ID> <Name>Radio_120</Name> <Manufacturer>University of Cambridge</Manufacturer> <Version>3</Version> <SourceStreams> <Stream> <StreamType>Audio</StreamType> <Occurence>Continuous</Occurence> <VCI>48</VCI> </Stream> <Stream> <StreamType>RDS</StreamType> <Occurence>event_driven</Occurence> <VCI>57</VCI> </Stream> </SourceStreams> <SinkStreams> <Stream> <StreamType>Audio</StreamType> <Occurence>Continuous</Occurence> <VCI>48</VCI> </Stream> <Stream> <StreamType>Key</StreamType> <Occurence>event_driven</Occurence> <VCI>50</VCI> </Stream> </SinkStreams> <Audio> <Encoding>PCM_16-bit_linear_stereo</Encoding> <SampleRate>44100</SampleRate> </Audio> </Device> We can see that it is controlled by a series of key presses. The syntax for these keys now needs to be known and encoded either in further XML or embeded in code fragments. References
|