Universal Plug and Play (UPnP) [56] is an industry initiative by Mirosoft [sic] to provide simple, robust, peer-to-peer connectivity among devices and PCs. Plug and Play (PnP) made it easier to setup, configure, and add peripherals to a PC, while the purpose of UPnP is to extend this simplicity throughout the network, enabling discovery and control of devices. Its target is zero configuration, invisible networking, as well as automatic discovery for the devices of many vendors. UPnP encompasses many existing, as well as new scenarios, such as home automation, printing, audio/video entertainment, kitchen appliances, etc., and is independent of operating systems, programming languages, or
physical media.

The basic components of a UPnP network are: devices, services, and control points. A
UPnP device contains services and nested devices. An XML device description document is hosted by each device; this document lists the set of services and properties of the device. A service is the smallest unit of control in UPnP. It is described in the XML document of the device, which also contains a pointer to the service description. A service consists of a state table, a control server, and an event server. The state table controls the state of the service through state variables. The control server updates the state according to action requests. The event server notifies interested subscribers when the service state changes. A controller is capable of discovering and controlling other devices. For true peer-to-peer functionality, devices should incorporate control point functionality. There is no central registry in UPnP, at least not necessarily.

UPnP uses many existing, standard protocols, so that UPnP devices can fit seamlessly and without effort into the existing networks. TCP/IP is the base on which the UPnP protocols are built, as well as many protocols that go with it, such as UDP, ARP, DHCP and DNS. HTTP is a core part of UPnP and its aspects are based on HTTP or its variants. The Simple Service Discovery Protocol (SSDP) defines how to find network services. It is both for control points to locate services on the network, as well as for devices to announce their availability. A UPnP control point, when booting up, can send a search request to discover devices and services. UPnP devices, on the other hand, listen on the multicast port. If the search criteria match, a unicast reply is sent. In the same way, a device, when plugged in, will send out multiple SSDP presence announcements. Apart from the leasing concept that UPnP also shares, SSDP provides a way for a device to notify that it is leaving the network.

The Generic Event Notification Architecture (GENA) defines the concepts of subscribers and publishers of notifications. The GENA formats are used to create these announcements that are sent using SSDP. SOAPis [sic] used in UPnP to execute remote procedure calls, as well as to deliver control messages and return results or error messages to the control points. XML is used in UPnP in device and service descriptions, control [messages and eventing.]

UPnP [9] is an industry initiative by Mirosoft [sic] to provide simple, robust, peer-to-peer connectivity among devices and PCs. Plug and Play (PnP) made it easier to setup, configure, and add peripherals to a PC, while the purpose of UPnP is to extend this simplicity throughout the network, enabling discovery and control of devices. Its target is zero-configuration, invisible networking, as well as automatic discovery for the devices of many vendors. UPnP encompasses many existing, as well as new scenarios, such as home automation, printing, audio/video entertainment, kitchen appliances, etc. UPnP is independent of operating systems, programming languages, or physical media.

The basic components of a UPnP network are: devices, services, and control points. A UPnP device contains services and nested devices. An XML device description document is hosted by each device; this document lists the set of services and properties of the device. A service is the smallest unit of control in UPnP. It is described in the XML document of the device, which also contains a pointer to the service description. A service consists of a state table, a control server, and an event server. The state table controls the state of the service through state variables. The control server updates the state according to action requests. The event server notifies interested subscribers when the service state changes. A controller is capable of discovering and controlling other devices. For true peer-to-peer functionality, devices should incorporate control point functionality. There

[Seite 3]

is no central registry in UPnP, at least not necessarily [3, 5].

UPnP uses many existing, standard protocols, so that UPnP devices can fit seamlessly and without effort into the existing networks [9]. TCP/IP is the base on which the UPnP protocols are built, as well as many protocols that go with it, such as UDP, ARP, DHCP and DNS. HTTP is a core part of UPnP. All UPnP aspects are based on HTTP or its variants.

The Simple Service Discovery Protocol (SSDP) defines how to find network services [9]. It is both for control points to locate services on the network, as well as for devices to announce their availability. A UPnP control point, when booting up, can send a search request to discover devices and services. UPnP devices, on the other hand, listen on the multicast port. If the search criteria match, a unicast reply is sent. In the same way, a device, when plugged in, will send out multiple SSDP presence announcements. Apart from the leasing concept that UPnP also shares, SSDP provides a way for a device to notify that it is leaving the network.

The Generic Event Notification Architecture (GENA) defines the concepts of subscribers and publishers of notifications. The GENA formats are used to create these announcements that are sent using SSDP [14]. Simple Object Access Protocol (SOAP) [13] is used in UPnP to execute remote procedure calls, as well as to deliver control messages and return results or error messages to the control points. XML is used in UPnP in device and service descriptions, control messages and eventing.

[XML is used in UPnP in device and service descriptions, control] messages and eventing. The advertisement message that a device issues contains a URL that directs to an XML file in the network, which describes the capabilities of the device. Each UPnP device must be a DHCP client and search for a DHCP server when connected to a network. In the lack of a DHCP server it must use Auto IP to get an address: the device randomly chooses an address, and then makes an ARP request to see if it is already occupied. This mechanism minimizes administration requirements.

2.5.2 Jini

Jini [57] is a network architecture for distributed systems, developed by Sun Microsystems in Java. The aim of this architecture is to make the network dynamic and self-administered, where services are added and deleted in a flexible manner. More precisely, the purpose is to end up with a monolithic system where users are able to not only share services and resources in a network, but have easy access to the services, even though the user's location may change. In a way, Jini can be considered as an extension of the Java application environment from a single machine to the whole network. Jini is based on Java environment, which offers built-in security for executing code from another machine and adds functionality on top of that to support the moving of components in a distributed system, as compared to the easy movement of objects in a Java application environment.

Jini makes the assumption that the devices connected to the network have a certain memory capacity and processing power. The limitation on the devices that can be connected directly to the network is a Java legacy; the devices need to have the JVM. Other devices not meeting this criteria need to be presented to the network by means of a proxy, which is a piece of hardware and/or software that meets the above-mentioned requirements. The service proxy has the drawback that in order to have no need for drivers, manufacturers must agree to a common interface. This is hard to achieve for every kind of device, and is exacerbated by the fact that each device tends to encompass multiple and different functionalities. There is benefit from the JVM: it makes Jini platform independent, but the JVM is heavy for hand-held devices and embedded systems. As for Java, Jini depends on the Java application environment, rather than on the Java programming language. Any language, as claimed, producing compliant bytecode can be used. However, practically, only the Java language is used.

Services are crucial to the Jini architecture. They can be used by a person, a program, or another service. Some examples of services are: storage, a computation, a hardware device, a user, devices such as printers, software such as applications, information such as databases. A Jini system is made up of services that can be collected in order to complete a particular task. A service can use another service, a client may be a service for another client. A service protocol is used for the communication between services. The one Jini offers is a set of interfaces that define critical service interaction between services. It can be extended further. A lookup service is used to find and resolve services. What it does is a mapping of the interfaces that indicate the functionality of a service to sets of objects implementing the service. A service has to be registered in at least one lookup service. A Jini service provider registers itself with every discovered lookup service. An object can itself consist of other services, this makes room for hierarchical services and lookup. Furthermore, objects may also be the encapsulation of other naming or directory services. References to the Jini lookup system can also be placed in other naming and directory services. In this way, bridging between the Jini lookup system and other forms of lookup service is created.

The discovery, join and lookup protocols are the heart of the Jini architecture.

Jini [8] is a network architecture for distributed systems; it is developed by Sun Microsystems in Java. The aim of this architecure [sic] is to make the network dynamic and self-administered, where services are added and deleted in a flexible manner. More precisely, the purpose is to end up with a system where users are able to share services and resources in a network; where users have easy access to the services, even though the user’s location may change; where building, maintaining, and changing devices, software, or users is made simple. In a way, Jini can be considered as an extension of the Java application environment from a single machine to the whole network. The Java environment, on which Jini is based, offers built-in security for executing code from another machine. Jini adds functionality on top of that to support the moving of components in a distributed system, as compared to the easy movement of objects in a Java application environment.

[Seite 2]

Jini makes the assumption that the devices connected to the network have a certain memory capacity and processing power. The limitation on the devices that can be connected directly to the network is a Java legacy; the devices need to have the JVM. Other devices not meeting this criteria need to be presented to the network by means of a proxy, which is a piece of hardware and/or software that meets the abovementioned requirements. The service proxy has the drawback that in order to have no need for drivers, manufacturers must agree to a common interface. This is hard to achieve for every kind of device, and is exacerbated by the fact that each device tends to encompass multiple and different functionalities. There is benefit from the JVM: it makes Jini platform-independent, but the JVM is heavy for handheld devices and embedded systems. As for Java, Jini depends on the Java application environment, rather than on the Java programming language. Any language, as claimed, producing compliant bytecodes can be used. However, practically, only the Java language is used. [...]

Services are crucial to the Jini architecture [8, 11]. They can be used by a person, a program, or another service. Some examples of services are: storage, a computation, a hardware device, a user, devices such as printers, software such as applications, information such as databases. A Jini system is made up of services that can be collected in order to complete a particular task. A service can use another service, a client may be a service for another client. A service protocol is used for the communication between services. The one Jini offers is a set of interfaces that define critical service interaction between services. It can be extended further.

A lookup service is used to find and resolve services. What it does is a mapping of the interfaces that indicate the functionality of a service to sets of objects implementing the service. A service has to be registered in at least one lookup service. A Jini service provider registers itself with every discovered lookup service [3]. An object can itself consist of other services, this makes room for hierarchical services and lookup. Furthermore, objects may also be the encapsulation of other naming or directory services. References to the Jini lookup system can also be placed in other naming and directory services. In this way, bridging between the Jini lookup system and other forms of lookup service is created.

The discovery, join and lookup protocols are the heart of the Jini architecture [8].

[Seite 3]

XML is used in UPnP in device and service descriptions, control messages and eventing. The advertisement message that a device issues contains a URL that directs to an XML file in the network, which describes the capabilities of the device [3].

[...]

Each UPnP device must be a DHCP client and search for a DHCP server when connected to a network. In the lack of a DHCP server it must use Auto IP to get an address: the device randomly chooses an address, and then makes an ARP request to see if it is already occupied. This mechanism minimizes administration requirements.

[The] discovery protocol is used when a device looks for a lookup service to register with. The join protocol is used when a service has located the lookup service and wants to join it. The lookup protocol is used when a client needs to locate and invoke a service. Discovery/join is how a service is added to the system. The service provider multicasts a request for local lookup services to identify themselves (discovery). After this, a service object is loaded into the lookup service (joining). This service object has the Java interface for the service including the methods of the interface to be invoked for using the service. There can also be other descriptive attributes. The lookup process ensures that a copy of the service object is loaded into the client. The client can now use the service. Java Remote Method Invocation (RMI) can be used for the communication between services. RMI basically implements the remote procedure call mechanisms in Java. It allows data as well as objects to be passed through the network.

With Jini, administration is still needed, because when a device is introduced to the network, it needs to be assigned an IP. Jini supports distributed events: an object can register its interest in events of another object and be notified whenever these events happen. This adds reliability guarantees to the architecture. Interfaces to devices have to be implemented for the Jini architecture to work. This is a disadvantage for Jini, since other service discovery protocols have them already available for consumer electronics.

2.5.3 SLP

SLP [58] is an IETF standard for service discovery. It enables the discovery and selection of a wide range of services accessible through an IP network. With SLP, a user needs only to search for a particular type of service, and optionally for attributes associated with it. It has three major software entities: User Agent (UA), Service Agent (SA), and Directory Agent (DA).

The SA advertises the location and attributes of one or more services on behalf of them by using broadcasts. It also replies with IP unicast to requests for these services. The services register and deregister with the SA. Each registrations has a lifetime and reregistration is required periodically. It is the same leasing concept already discussed in previous protocols.

The UA receives requests from a client application and forwards multicast requests to SAs. Hence, there is little network overhead for SA discovery. The SA unicasts a response back with the service URL and possible attributes if there is a match with the registered services.

The DA is a central information repository and it is optional. Its main function is to improve the performance of SLP. It can be thought of as a tier between the UAs and the SAs, which communicate with the DA instead of with each other. DAs relieve the network traffic from many multicast requests; the effect is more visible in large network, where multicast traffic can increases sharply because there are many SAs and UAs. A DA keeps the SA advertisements, and responds to UA requests. An SA registers itself with a DA. The registration contains the URL for the services, the lifetime, and descriptive attributes of the service. The registration should be refreshed periodically. A UA sends a request message to the DA, which in turn sends a message containing the URL of the service matched against the UA needs. SLP can work both with and without a DA: (1) with DA, information about the services is kept in the DA, so that the UA sends a query there for services; (2) without a DA, the UA multicasts service requests to the network, and a SA offering the service would reply back. In small networks, there may be no real need for a DA.

SLP scales well in large networks; the reason is the minimal use of multicast messages [and the fact that it can have multiple DAs.]

[58] Choonhwa Lee, Sumi Helal, Protocols for Service Discovery in Dynamic and Mobile Networks. International Journal of Computer Research, 2002.

[Seite 2]

The discovery protocol is used when a device looks for a lookup service to register with. The join protocol is used when a service has located the lookup service and wants to join it. The lookup protocol is used when a client needs to locate and invoke a service. Discovery/join is how a service is added to the system. The service provider multicasts a request for local lookup services to identify themselves (discovery). After this, a service object is loaded into the lookup service (joining). This service object has the Java interface for the service including the methods of the interface to be invoked for using the service. There can also be other descriptive attributes. The lookup process ensures that a copy of the service object is loaded into the client. The client can now use the service.

Java Remote Method Invocation (RMI) can be used for the communication between services [8, 11]. RMI basically implements the remote procedure call mechanisms in Java. It allows data as well as objects to be passed through the network.

[...]

With Jini, administration is still needed, because when a device is introduced to the network, it needs to be assigned an IP. Jini supports distributed events: an object can register its interest in events of another object and be notified whenever these events happen. This adds reliability guarantees to the architecture. Interfaces to devices have to be implemented for the Jini architecture to work. This is a disadvantage for Jini, since other SDPs have them already available for consumer electronics.

[Seite 3]

2.4 SLP

SLP [5] is an IETF standard for service discovery. It enables the discovery and selection of a wide range of services ac-

[Seite 4]

cessible through an IP network. With SLP, a user needs only to search for a particular type of service, and optionally for attributes associated with it.

It has three major software entities [5]: User Agent (UA), Service Agent (SA), and Directory Agent (DA).

The SA advertises the location and attributes of one or more services on behalf of them by using broadcasts. It also replies with IP unicasts to requests for these services. The services register and deregister with the SA. Each registrations has a lifetime and reregistration is required periodically. It is the same leasing concept already discussed in previous protocols.

The UA receives requests from a client application and forwards multicast requests to SAs. Hence, there is little network overhead for SA discovery. The SA unicasts a response back with the service URL and possible attributes if there is a match with the registered services.

DA is a central information repository and it is optional. Its main function is to improve the performance of SLP. It can be thought of as a tier between the UAs and the SAs, which comminicate [sic] with the DA instead of with each-other [sic]. DAs relieve the network traffic from many multicast requests; the effect is more visible in large network, where multicast traffic can increases sharply because there are many SAs and UAs. A DA keeps the SA advertisements, and responds to UA requests. An SA registers itself with a DA. The registration contains the URL for the services, the lifetime, and descriptive attributes of the service. The registration should be refreshed periodically. A UA sends a request message to the DA, which in turn sends a message containig the URL of the service matched against the UA needs. SLP can work both with and without a DA: (1) with
DA, information about the services is kept in the DA, so that the UA sends a query there for services; (2) without a DA, the UA multicasts service requests to the network, and a SA offering the service would reply back [5]. In small networks, there may be no real need for a DA.

SLP scales well in large networks; the reason is the minimal use of multicast messages and the fact that it can have multiple DAs.

[5] Choonhwa Lee and Sumi Helal. Protocols for Service
Discovery in Dynamic and Mobile Networks. International
Journal of Computer Research, 2002.

It has a flexible and scalable architecture, where service browsing and human interaction is possible. SLP offers filtered search for attributes and predicates, such as AND, OR, comparators, and substring matching. SLP shares the concept of leasing with Jini and UPnP. Services can be deployed in small networks without any special configuration or deployment. It works even if there is no DNS, DHCP, SLP DA, or routing. Therefore, home networks would benefit much from the automation of service discovery, because they often lack network administration. However, the architecture with DAs makes the system vulnerable to a single point of failure. SLP is an open source, vendor independent and already implemented. It has the advantage of not depending on any programming language.

2.5.4 Bluetooth SDP

Bluetooth is a transmission technology, meant for short-range (10m) wireless communication between low-power devices. Bluetooth devices form a personal area network, a piconet, with a maximum of 8 members. Groups of piconets communicating with each-other form a scatternet. Every Bluetooth SDP device has to implement a SDP server that provides services. The server has a list of service records, each with a list of attributes that represent different service classes. A Bluetooth SDP client sends a request message with the list of service classes.

Bluetooth is designed for Bluetooth environments, therefore, it offers limited functionality compared to other SDPs. Its functionalities are: search for services by service type; search for services by service attributes; and service browsing without a priori knowledge of the service characteristics. The Bluetooth SDP does not include functionality for accessing services. After services have been discovered with it, the selection, access, and usage can be done with mechanisms out of the scope of SDP, for example by other SDPs such as SLP and Salutation. SDP can coexist with other SDPs, but they are not a necessity.

The strong point of Bluetooth in the home environment is the lack of wires, while the short range it provides is a disadvantage. Also, it has a peer-to-peer connectivity, which does not scale well, because typically the systems lack resources. Another disadvantage is the lack of event notification when services become unavailable. The Bluetooth security mechanisms offer either one-way, two-way, or no authentication. When authentication is used, the Bluetooth devices generate a secure connection with a pairing process that makes use of PIN codes entered by users. But for home environment usage, maybe security and privacy have to be addressed also in higher layers. Bluetooth has huge implementation opportunities in home environments. Apart from cell phones and PCs which have already been implemented, there are other potentials. Home automation, for example, could replace doorbells. This would eliminate unnecessary wires around the place. Other goods, such as toys or entertainment devices, could be another area of implementation.

[Seite 4]

It has a flexible and scalable architecture, where service browsing and human interaction is possible. SLP offers filtered search for attributes and predicates, such as AND, OR, comparators, and substring matching [5]. SLP shares the concept of leasing with Jini and UPnP.

Services can be deployed in small networks without any special configuration or deployment. It works even if there is no DNS, DHCP, SLP DA, or routing. Therefore, home networks would benefit much from the automation of service discovery, because they often lack network administration. However, the architecture with DAs makes the system vulnerable to a single point of failure.

SLP is an open source, vendor-independent and already implemented [4]. It has the advantage of not depending on any programming language [5].

[Seite 5]

2.6 Bluetooth SDP

Bluetooth is a transmission technology, meant for short-range (10m) wireless communication between low-power devices. Bluetooth devices form a personal area network, a piconet, with a maximum of 8 members. Groups of piconets communicating with each-other form a scatternet. Every Bluetooth SDP device has to implement a SDP server that provides services. The server has a list of service records, each with a list of attributes that represent different service classes. A Bluetooth SDP client sends a request message with the list of service classes.

Bluetooth is designed for Bluetooth environments, therefore, it offers limited functionality compared to other SDPs. Its functionalities are: search for services by service type; search for services by service attributes; and service browsing without a priori knowledge of the service characteristics. The Bluetooth SDP does not include functionality for accessing services. After services have been discovered with it, the selection, access, and usage can be done with mechanisms out of the scope of SDP, for example by other SDPs such as SLP and Salutation. SDP can coexist with other SDPs, but they are not a necessity [4].

The strong point of Bluetooth in the home environment is the lack of wires, while the short range it provides is a disadvantage. Also, it has a peer-to-peer connectivity, which does not scale well, because typically the systems lack resoures [sic]. Another disadvantage is the lack of event notification when services become unavailable [5]. The Bluetooth security mechanisms offer either one-way, two-way, or no authentication. When authentication is used, the Bluetooth devices generate a secure connection with a pairing process that makes use of PIN codes entered by users. But for home environment usage, maybe security and privacy have to be addressed also in higher layers.

Bluetooth has huge implementation opportunities in home environments. Apart from cell phones and PCs which have already been implemented, there are other potentials. Home automation, for example, could replace doorbells. This would eliminate unnecessary wires around the place. Other goods, such as toys or entertainment devices, could be another area of implementation.

[4] Christian Bettstetter and Christoph Renner. A Comparison of Service Discovery Protocols and Implementation of the Service Location Protocol. Proc. EUNICE Open European Summer School. September 2000.

[5] Choonhwa Lee and Sumi Helal. Protocols for Service Discovery in Dynamic and Mobile Networks. International Journal of Computer Research, 2002.