View page as slide show

Wireless service engineering

Service Discovery

Finding services

  • Device discovery
    • To find out what is surrounding us
  • Service Discovery
    • To see what is available
    • Before service can be used it has to be found
  • Service Selection

Device Discovery

  • How to locate the physical device we want to communicate with?
    • touch it (NFC approach)
    • point towards it (The infra red approach)
    • Send queries to find out the neighbours (RF approach)
      • Hope that neighbours here the query and answer
  • Device discovery finds physical devices, service discovery is used to find application.
    • In order to find services on device the device has to be found
    • Service discovery can also provide the adress to the device providing the service.

Service Discovery

  • Tries to answer to the questions
    • What types of services are available
    • Where are certain services
    • What is required from client to use the service
    • How to contact the service
  • Can help in configuration problems
    • All necessary information is gained through service discovery to use the device/ service
    • Mobile users using mobile services cannot be forced to do configuration manually.
    • Mobility has no place for preinstalled drivers.
  • Services may have subtypes
    • high resolution printer is subtype of printer
  • Dynamic service status update
    • Services can come and go.
  • Eventing
    • Asynchronous notifications about changes in condition of service.
  • Garbage collection
    • get rid of out-of-date data from seervice catalogs
  • Two operational modes
  1. Discovery of services on demand
    • Word processor needs to use a printer
    • Digital camera requires more light
    • John wants to find multipalyer games
  2. Service browsing
    • Client can browse through list of available services

General service discovery architecture

  • Client
    • Conducts the service discovery
  • Catalog
    • Contains the information about the services
  • Server
    • Contains the service
    • Informs the catalog about the service

General service discovery operation

  • Setup
  1. Service gets started
  2. Service contacts service catalog and informs it is available
  • Service discovery
  1. Client finds the catalog
    • either to predefined address or using broadcasting (e.g. device discovery)
  2. Client sends request
    • about the location of the certain service and parameters to use it
    • list of available services
  3. Catalog responds with the service location and necessary parameters or a list of services
  4. Client contacts the service with the gained parameters

Service Discovery Protocols

  • Bluetooth SDP
    • For Bluetooth PAN services
  • SLP (Service Location Protocol)
    • IETF standard for IP based networks
  • JINI
    • Java based solution
  • UPnP (Universal Plug'n'play)
    • For hardware discovery
  • UDDI (Universal Description, Discovery and Integration)
    • Web services
  • Questions?
    • Does service and client support same service discovery protocols
      • Bridging between different protocols exist
    • Does service and client use same catalog?

SLP

  • IETF standard
    • RFC 2608: SLPv2 specications
    • RFC 2609 Service Templates
    • RFC 2614 SLP API's
  • Three entities
    • Service agent (SA)
      • Advertises the service and it's parameters
    • User agent (UA)
      • Finds the services for the client program
    • Directory agent (DA)
      • Cache information about services
      • Optional
  • Services can have different scopes
    • Some services can be public i.e. everyone can see them e.g. public printers
    • Some services can be private and thus only specic devices can see them e.g. printer on researcher work room.
  • API defined for C and Java

SLP on the run

  • Service discovery without using DA

1. UA sends multicast message stating the services it requires

  • contains: service type and essential characteristics of the service

2. SA(s) responds with using Unicast

  • Service discovery with DA
    • Services registrate themselves to DA
    • The client sends unicast request to DA instead of using multicast.
      • DA location can be statically configured to client
      • DA location maybe gained through DHCP
      • DA is a service so multicast request for DA service can be issued.
    • Reduces the amount of traffic required.
    • Reduces the load on services
    • Extends discovery over the multicast perimter

Service URL

  • Naming convention in SLP
  • Service URL service : service type : site url path
    • service at the beginning states that we are having a service URL (not HTTP, FTP or something else)
    • service type identifies surprisingly the type of service
      • special naming authority can be defined along with service type and is separated by dot service type.naming authority
    • site url path defines the way to access the actual service
      • the actual format is defined on service template of the used type
  • Examples

service:printer:lpr:printer.lut.fi/color service:mud.mygames:tcp:192.168.1.15:2222

service:image-service.test:images.com/;format=JPEG;resolution=1024×768 ===== Service types in SLP ===== * Is used to match the requests and the services * Abstract service type defines the basic type * Subclasses are used to refine the abstract type to concrete type * Service template defines the format how the access to this type of service is transmitted * For each service type there a service template that defines how to interpret the rest of the message ===== Service templates ===== * The actual format for accessing service and show the parameters. * e.g. defines the url path of service URL * Has five parts 1. Template type defines * the service type this template is for template-type=service type.NamingAuthority template-type=printer 2. Template version * version of template template-version=0.0 ===== ===== 3. Description of template * Human readable description of service template-description = This service lets you print everything 4. template url syntax * The actual format of url path using augmented backus naur form (ABNF) template-url-syntax = url path url path=“;ports=” list of ports list of ports = port /port “,” list of ports port = 1*DIGIT * if no url path is not used then template-url-syntax = url path= ; ===== ===== 5. specification of attributes * defines the attributes that for the service type. * includes name of attribute, type of attribute, human readable block writeable= boolean X #whether the disk service is readonly or not maxlinelenght=integer 80 #what is the maximum size per line of text to be stored * The fields are separated with an empty line ===== Example template ===== template-type = printer:raw-tcp template-version = 1.0 template-description = The printer:raw-tcp: URL describes a transparent bidirectional communication channel for printing. Print data, status, messages, etc is written or read by opening a TCP connection to the port in the service URL. How data is formatted and sent across the connection is decided by the printing client and the printer service and is not defined by this template. template-url-syntax= url-path = ippurl / lprurl / raw-tcp-url ===== ===== ; This template adds 'raw-tcp-url' to the url-path ; definition in the 'printer' service template. ; 'ippurl' and 'lprurl' as defined in the 'printer' ; service template. raw-tcp-url = “raw-tcp:” hostport

; raw-tcp URLs don't have a path section.
hostport = host ":" port
; raw-tcp doesn't have a well-known port assigned by
; IANA. The port must therefor be specified in all
; raw-tcp URLs.
; 'host' and 'port' is as defined in the 'printer'
; service template.
ieee-1284-device-id = STRING L O
Last modified: 2013/07/01 14:42