GB2411548A

GB2411548A - Automatic service discovery

Info

Publication number: GB2411548A
Application number: GB0404428A
Authority: GB
Inventors: Fan Zhong
Original assignee: Toshiba Research Europe Ltd
Current assignee: Toshiba Europe Ltd
Priority date: 2004-02-27
Filing date: 2004-02-27
Publication date: 2005-08-31
Anticipated expiration: 2024-02-27
Also published as: GB2411548B; GB0404428D0

Abstract

The invention provides a system which allows user agents, acting to locate required services for a device, to identify suitable service agents to provide the service. The user agent sends service request messages and the service agent responds with service reply messages if it can provide the service. Attached to these messages can be quality of service information for specifying desired service requirements in the case of the requests or service quality availability messages in the case of a reply. The quality of service information can relate to application quality of service, i.e. the capability of the service provider or path quality of service, i.e. the link between the service agent and the user agent.

Description

241 1 548 Automatic Service Discovery The present invention relates to

identifying and establishing a service provider over a network, in particular an ad-hoc network system.

In networks and in particular ad-hoc networks devices may join or leave the network at any time and so the array of services and demands for those services is highly dynamic.

In order to provide a system to allow devices to determine whether a particular service is available and also for a device providing a service to make other devices aware of its functionality, a protocol is required to exchange this information between devices. A number of protocols have been proposed for providing a framework within which information can be exchanged between devices to establish links for providing and obtaining a service. The technical white paper from SUN Microsystems entitled "Jini Technology Architectural Overview" (1999) describes a structure for allowing service providers and service users to communicate with each other in order to make use of each other's services. Also, the IETF Request for Comments entitled "Service Location Protocol, Version 2", RFC 2608, 1999, by Guttman et al, proposes a service location protocol for providing a framework for the discovery and selection of network services.

These proposals set out in detail the means for users of services and service providers to locate each other and establish a link for making use of the available service. These protocols do not consider the quality of service requirements of applications but instead they are mainly concerned with the service advertisement, discovery and location process rather than the quality of the service to be provided and the quality of the communications link over which the service is to be provided. However, this quality of service is very important in some applications such as real-time high-quality audio/video applications such as those envisaged in home entertainment networks but also in many other applications, for example, a display device providing a service of displaying a real time streamed video signal. The device generating the video signal may seek out a display device over the local ad-hoc network. Any existing protocols would allow such a device to be found but would provide no guarantee of the quality of service. Thus, there would be no consideration of the capabilities of the display device such as its processing capability or memory availability. In addition, no consideration of the path quality of service, e.g. the delay between the devices or the bandwidth of the link, is considered.

It would be desirable to provide a system which allows quality of service information to be transferred between devices so that the available quality of service can be determined and a decision taken on the viability of using the available service from a given device.

This is preferably achieved with minimum transmission overhead and with the least delay in establishing that information. To minimise delay, it would be helpful if this were done before or whilst a relationship is being established.

Therefore, according to the present invention there is provided a method for discovering a service provider in a network comprising: sending a service request message; receiving service reply messages issued in response to said service request message by service providers; and selecting a service provider based upon said service reply messages, wherein the service request message includes quality of service requirement information and/or said service reply messages include quality of service provision information relating to the issuing service provider.

The present invention further provides a service discovery agent for discovering a service provider in a network capable of sending service request messages andlor receiving service reply messages containing including quality of service requirement information to allow the specification of quality of service requirements of a service provider and to determine the quality of service availability of a service provider, respectively.

The present invention provides a way of sending quality of service requirements between user agents needing a service and service providers, at the same time as discovering available services. This avoids the need to establish what services are available before determining their quality of service. This helps to ensure faster selection of service providers, reduce network traffic, reduce processing overhead in the service provider (SA) and the service user (UA) by filtering out inappropriate service providers at an early stage.

Preferably, where a service request message includes quality of service requirement information, the quality of service requirement information includes one or more first sets of data, each of which specifies the criteria which must be met by a service provider. This allows the service provider to determine if it can provide that service level and if not, it can determine to make no response to the message.

Additionally, the quality of service requirement information sent to prospective service providers can includes one or more second sets of data which specify the criteria which must be met by a path between the sender of the service request message and a service provider. This allows the quality of the path to be established and if it fails to meet the required level, the service provider can again determine not to respond to the service request, even if it can match the application quality of service required.

In the above case, the one or more second data sets may be modified by intermediate nodes according to the characteristics of the preceding link. Thus, as the messages are passed from node to node along the path between the sender and a service provider, the path characteristics can be determined in order to establish a picture of the characteristics of the overall path..

Where quality of service information is sent to the service provider in the service request message, the service provider can determine whether it meets the requirements specified by the service requirement information, before sending a service reply message. If it does not meet the requirements than it may simply not respond.

Where the service reply messages include quality of service provision information, it may include one or more third sets of data, which specify a quality of service measure of the service provider. This can be used by the user agent to determine if the service provider meets its own service requirements.

The quality of service provision information may include one or more fourth sets of data relating to quality of service information of the path between a service provider and the sender. This allows the user agent to determine if the path between the service provider and the user agent meets the desired requirements. The UA may reject an SA that meets the service requirements but which connects over a path which is inadequate.

It should be noted that the service requirements sent to the SA and those received by the UA may be different. This allows two stages of filtering, to maximise the filtering process. Furthermore, the service requirements may include more than one parameter specifying different requirements.

The first, second, third and fourth sets of data are preferably concatenated with the service requirement information. This helps to keep the message length to a minimum, e.g. to reduce network traffic.

The present invention may be used in any kind of network including an adhoc network, a wireless ad-hoc network, and combinations of wired and wireless networks.

The present invention may be applied to any kind of service discovery protocol, including the IETF service location protocol.

The present invention can be implemented either in hardware or on software in a processor. Further the present invention can be implemented in a combination of hardware and software. The present invention can also be implemented by a single processing apparatus or a distributed network of processing apparatuses.

Since the present invention can be implemented by software, the present invention encompasses computer code provided to a general purpose processor on any suitable carrier medium. The carrier medium can comprise any storage medium such as a floppy disk, a CD ROM, a magnetic device or a programmable memory device, or any transient medium such as any signal e.g. an electrical, optical or microwave signal.

The present invention will be described in more detail by reference to a specific embodiment in which: Figure 1 shows an example of a simple user and service provider system; Figure 2 shows a system having a directory agent; Figure 3 shows an example of a communication path between a user agent and a service agent; Figure 4 is table of exemplary link characteristics of the network of figure 3; Figure 5 shows a representation of a service location protocol message header; Figure 6 shows the structure of a generic message extension; and Figure 7 shows the structure of a quality of service metric message extension.

The IETF Service Location Protocol (SLP) provides a framework for devices to determine existence, availability, location and configuration information about services available on a network. Historically, if a service was required, it was necessary to manually configure a device to identify where a service could be located. SLPs avoid the need for this manual identification of a service provider. SLP provides a framework within which a device requiring a service can identify and access a service automatically without the intervention of a user.

This automatic functionality is particularly useful in ad-hoc networks where the configuration and members of the network may change rapidly in relatively short periods of time.

Figure 1 shows an example of a simple exchange to attempt to establish a provision of a service. A user agent is effectively a process operating within a device in order to establish the existence and location of some desired service. Similarly, a device which provides a service, or service provider, will have a service agent which is operative to advertise the available services to potential users.

When a user agent enters a network or is initially switched on, it issues a service request SrvRqst on behalf of its client device. The SrvRqst specifies the features of the desired service. In this example, the SrvRqst message is multicast to be received directly by any service agents. Any service agent receiving a SrvRqst message will determine whether it is able to provide that service or is advertising that service. If so, it will send a reply to the user agent. The service reply (SrvRply) message will be unicast back to the user agent using the identification information included in the SrvRqst message.

Figure 2 shows an alternative configuration in which a third party directory agent is provided. In this arrangement, the directory agent maintains a database of services advertised by service agents with which it is in contact. When a service agent first joins a network or is switched on, it initially issues a multicast message which is in the form of a SrvRqst asking for a directory agent service. In response to this request for service, the directory agent issues a SrvRply message indicating the availability of the directory agent service. Alternatively, when a directory agent first joins a network or is switched on, it can issue a multicast advertisement message advertising the directory service which will be received by any service agents. They would then issue a SrvReg message unicast to the newly discovered directory agent which would then acknowledge the registration of the service agent in its database by issuing a service acknowledge (SrvAck) message. This would be unicast back to the service agent.

Registration of a user agent with a directory agent operates in a similar way, with the user agent either multicasting a service request which is received by a directory agent and acknowledged accordingly or by the user agent already being aware of the directory agent and issuing a unicast service request direct to the directory agent. When a directory agent receives a service request from a user agent it determines whether there are any service agents which have recorded services in its database and issues a service acknowledgement (SrvAck) message which is unicast back to the user agent.

There are a number of other features of the service location protocol which are not set out in detail here but are well documented in the service location protocol document identified above.

SLP protocol defines the structure for the various types of message, e.g. SrvRqst, SrvRply. Each message includes a header such as that shown in Figure 5.

The header includes a function-ID which identifies the message type, e.g. service request; service reply; service registration, etc. The protocol defines a structure which allows extensions to be added so as to follow on from the header. These extension can serve all sorts of functions and allow extra functionality to be added to a basic message.

The header includes a 3-byte value identifying the start position of any extension. If this value is zero, then there is no extension but if the value is non-zero, the indicated value represents the start position of the first extension.

The general structure of an extension according to the service location protocol is shown in Figure 6. This includes an extension-ID to identify the type of extension.

This is followed by a 3-byte value identifying the location of the next extension. Again, this value is relative to the service location extension header start. If the offset value given is zero then this means there are no further extensions and the overall length of the current extension is determined by subtracting the total length of the SLP message given in the header minus the offset of the current extension. For example, the ID for an extension relating to delay over a link could be OxlOOO (i.e. 10006), the length could be 2-bytes and the units in milliseconds. However, this is merely exemplary and a detailed definition would depend upon various considerations such as the IANA (Internet Assigned Numbers Authority).

The embodiment of the present invention utilises the extension function of SLP to transfer quality of service metrics. Different types of quality of service metric are anticipated and a different extension-ID can be allocated to each different type of metric. Examples of the different types of metric are discussed in more detail below.

As indicated previously, the service location protocol can operate with either an architecture where there is a directory agent (DA) or one where there is no directory agent, in which case user agents and service agents communicate directly with each other. Architectures which do not have this directory structure are more suited to ad- hoc networks as there is no need for any infrastructure to be established. This is particularly convenient where the network is highly dynamic where it might not be practical to initialise directory agents. The example below considers the situation where no directory agent is present. However, the present invention is equally applicable to a situation where a directory agent is provided.

When a user agent wishes to obtain a certain service, it may have a predetermined quality of service level requirement. It can implement this service requirement in one of two ways. It can specify the quality of service requirement in advance so that service agents receiving the service request message know the user agent's quality of service requirements and can determine whether or not they can meet those QoS requirements.

If a user agent's request cannot be met by a service agent because it lacks the required quality of service then the service agent can simply complete the request as if it was not advertising the specified service. In this example, according to the service location protocol, the service agent would simply remain silent, i.e. ignore the service request.

Similarly, where a service agent has received a request from a user agent for a service which it is advertising, the service agent responds to the user agent. It can unicast a reply containing the service's location ID in a service reply message (SrvRply). The SrvRply message could carry a quality of service extension to provide QoS metrics to the user agent. When the service reply message is received by the user agent, it can analyse the quality of service metric in the QoS extension to determine if the service offered by the service agent meets its QoS requirements.

These two techniques can be used either together or separately. By sending out quality of service requirements, the user agents can provide an initial filtration of all available service agents to avoid receiving service replies from service agents which are advertising the desired service but are not able to provide the required QoS level. This provides a self filtering feature at the service agents. If a UA requests a service and there are 10 SAs which are advertising that service, then it would receive 10 SrvRply messages. If only 3 of the SAs have the required QoS capability, then by sending the QoS requirement with the SrvRqst message, the SAs self-filter themselves if they do not meet the required QoS parameters. In this way, only the 3 qualifying SAs respond with SrvRply messages, which simplifies the selection task of the UA, reduces the amount of network traffic, i.e. 3 replies instead of 10, and does this with a minimal data overhead piggybacked onto the service request message.

Alternatively, by receiving QoS metrics in the SrvRply message from service agents advertising the required service, the user agent can filter out the service agents to identify the service agent which could provide the most suitable combination of service and QoS. By providing QoS information in their reply, the UA can quickly determine which SA satisfies all its requirements and even which would do it the best. For example, if processor capability was the main consideration, the SAs could include processor speed metrics in the SrvRply extension. The UA could then use those metrics to select the best candidate. With multiple metrics, the UA can select the best available combination of QoS parameters.

By utilising the transmission of QoS metrics in both the SrvRqst message and the SrvRply message, the service agents can carry out self filtration; so that those service agents which cannot provide the required QoS do not respond. Then the user agent can filter out those service agents which do meet the minimum requirements to determine the most suitable service agent. To use a combination of the examples above, where the 3 SAs respond, they could include processor speed metrics to allow the UA to quickly select the best match from the already reduced (10 down to 3) subset of the SAs advertising the desired service.

By sending the QoS metric with the SrvRqst and SrvRply messages, the data overhead is minimised and the QoS metrics are established at an early stage. This avoids the need to establish potential SAs and then exchange QoS data in a separate message exchange and then to filter out the most suitable service agent to use. Thus by "piggy backing" QoS metrics on the service discovery packets, transmission overhead is kept to a minimum and service discovery can be carried out more quickly and with more appropriate selection based upon QoS requirements. As indicated above, this is particularly important in ad-hoc networks, particularly where the network configuration is dynamic and time critical real-time applications (e.g. video streaming) are required.

The present invention contemplates various types of QoS metrics. In particular, there are application level QoS (e.g. processor capability and availability, memory usage, etc. Of a service provider) and path QoS (e.g. path delay, bandwidth, reliability, etc.).

For application QoS, the UA can specify the desired parameters to allow the SA to determine if it can meet those requirements. Similarly, when QoS metrics have been transmitted back to the UA, the SA can include information about its application QoS in the SrvRply message. This allows the UA to easily choose between SAs which reply to its SrvRqst message.

It is slightly more complicated determining the path QoS as these must be estimated or calculated in real-time. It is well known that the delay of the signal path can be represented as the sum of the delays in the signal path between each of the intervening nodes between the UA and the SA. Similarly, the bandwidth of the link between a UA and an SA is simply the bandwidth of the link between each of the intervening nodes between the UA and SA with the smallest bandwidth.

In the present invention, each type of QoS metric will be transmitted in a separate extension. Each message may carry a single extension with one metric or several extensions with several QoS metrics. For example, if a UA transmits a SrvRqst message over the partial network shown in Figure 3 the message is passed from the UA to node A to node B to node C and on to the SA. In the example given in Figure 3, the UA 21 could send a SrvRqst message with an extension relating to path delay. Initially the QoS metric would indicate the maximum delay acceptable for a transmission from the UA 21 to the SA 25. As the message is passed over the link 26 to node A 22, the transmission delay is noted by node A and deducted from the value in the delay QoS metric. This is then used as the value in the extension when the SrvRqst message is transmitted to node B 23. When node B receives the message over the link 27, it notes the transmission delay and again deducts this from the QoS metric. This process is repeated when the message is passed over link 28 to node C 24 and finally over link 29 to the SA 25. When the SA receives the SrvRqst message it extracts the delay metric in the extension. If the transmission delay over the link exceeds the maximum delay allowed then the metric value will be zero. If the metric value is greater than zero then the SA knows that the transmission delay is less than the maximum delay allowed.

When the SA sends an SrvRply message in response to a SrvRqst, the delay QoS metric is initially zero. At each node along the way, the node notes the delay over the preceding link and adds this to the value in the delay QoS metric. Thus when the message is received by the UA, the total transmission delay of the link has been established. In this way, the SA can determine in advance, if the link to it from the UA meets the delay requirements of the UA and similarly, the UA can determine if the delay over the link from the SA to the UA meets its requirements.

Figure 4 is a table of exemplary characteristics of the links shown in figure 3. Figure 4 shows how the delay on each of the links along the path of the message signals has an associated delay. The cumulative delay column represents the QoS delay metric which will be included in the SrvRply message sent from node to node between the SA to the UA. Thus when the UA receives the SrvRply message it knows that the total delay over the link is ems for the example given in Figure 4. Similarly when the UA sends a SrvRqst message, it may have a maximum delay requirement of 1 Oms. If it sends the SrvRqst message with a value of 10 in a delay QoS extension, then when the message is received by the SA, the residual value will be 2ms and so the SA knows that the delay of the path is acceptable. Equally if the UAs requirement was a maximum delay of 5ms then when the message was received by the SA, the residual delay value would be O and the SA would know that the path QoS was inadequate and not respond to the request.

Where the available bandwidth of a link is a determining factor, then the SrvRqst message from the UA will include an extension with a desired bandwidth QoS metric.

Again when the service agent generates an SrvRply message in response SrvRqst with a bandwidth extension, the metric in the extension is initially a very large number. This message is passed to node C. Node C determines the local bandwidth in order to estimate the bandwidth of the link 29 between it and the SA when data is subsequently transmitted. Node C compares this to the metric currently in the bandwidth extension.

The smaller of these two numbers is then substituted as the new bandwidth QoS metric and the message is passed on to node B. Node B determines the local bandwidth and compares this to the bandwidth QoS metric in the received SrvRply message. In the example given in Figure 4, the estimated bandwidth of transmissions over the link 29 is 50kbps. Thus node C 24 compares this to the large value in the received SrvRply message and determines the new metric value to be 50kbps. Similarly at node B. the bandwidth of transmissions over the link 28 is determined to be 1 Okbps which is compared with the metric in received SrvRply message. As the 1 Okbps is the smaller value, the metric is updated with this new value. This process is repeated at node A. However as the value for the link 27 between node A and node B is lMbps, the existing metric value of lOkbps is retained. Similarly on the link 26, the bandwidth is greater than the existing metric and so the existing metric is retained. Thus when the UA receives the SrvRply message, the bandwidth QoS metric indicates lOkbps representing the link with the lowest bandwidth in the path between the UA and the SA. The UA can then determine whether or not the bandwidth is sufficient to meet its requirements. For example, where the UA receives several SrvRply messages from different SAs or from the same SAs but via different routes, it can determine which is the best SA and the best route to use.

In a further example, a UA may issue a service request message requiring a service which can be provided with a delay of less than 1 Oms and requiring lMb of memory at the service agent. The UA would therefore send out an SrvRqst message with one extension relating to the delay and another extension identifying the memory requirement. This will be transmitted over the network and received by one or more SAs. The recipient SA will be able to determine if the link to it from the UA had a sufficiently small delay by looking at the residual amount in the delay metric.

Assuming the delay was satisfactory, the SA can then compare the memory requirement metric to its own memory availability. If both conditions are satisfied then the SA can issue an SrvRply message to the UA indicating that it is advertising the service required and can meet the QoS requirement specified by the UA. That SrvRply message may include the same or different QoS metrics to allow the UA to make a further decision.

In the above description, no directory agent is present. However, the invention is applicable to situations where a directory agent is present. In this case, a UA issues a SrvRqst which is received by a Directory Agent (DA). The DA then responds with a SrvRply message in a similar way to an SA. The DA maintains a directory of SA's which it is acting on behalf of. In this directory, it can store information on the QoS parameters of the SA. It can use this information to determine if the SAs it acts for meets the required criteria. Only if they do meet the required criteria does the DA respond with a SrvRply message to identifying a qualifying SA. As above, the SrvRply message may contain QoS information about the SA to allow the UA to determine the suitability of an SA. In this example, path QoS is not applicable as the message exchange is between the UA and the DA and the path between the UA and the SA is the important one. However, path QoS considerations may still be applied by subsequently analysing the path from the UA to the SA.

In the examples given above, the IETF service location protocol (SLP) is described as an example of a service discovery protocol. However, the present invention is not limited to only this specific type of protocol.The skilled man will appreciate that different service discovery protocols can be implemented in which service discovery and service reply messages are passed between user agents and service agents with QoS information appended to the request and reply as extensions.

Claims

CLAIMS: 1. A method for discovering a service provider in a network

comprising: sending a service request message; receiving service reply messages issued in response to said service request message by service providers; and selecting a service provider based upon said service reply messages, wherein the service request message includes quality of service requirement information and/or said service reply messages include quality of service provision information relating to the issuing service provider.
2. A method according to claim 1, wherein the service request message includes quality of service requirement information.
3. A method according to claim 2, wherein the quality of service requirement information includes one or more first sets of data, each of which specifies the criteria which must be met by a service provider.
4. A method according to claim 2 or 3, wherein the quality of service requirement information includes one or more second sets of data, each of which specifies the criteria which must be met by a path between the sender of the service request message and a service provider.
5. A method according to claim 4, wherein said one or more second data sets may be modified according to the characteristics of the preceding link, as they are passed from node to node along the path between the sender and a service provider.
6. A method according to claim 3, 4 or 5, wherein each set of said first and/or second sets of data is concatenated onto the end of the service requirement information.
7. A method according to any one of claims 2 to 6, further comprising determining that a service provider receiving said service requirement information can meet the requirements specified by said service requirement information, before sending a service reply message.
8. A method according to claim 1 or 2, wherein service reply messages include quality of service provision information.
9. A method according to claim 8, wherein the quality of service provision information includes one or more third sets of data, each of which specifies a quality of service measure of the service provider.
10. A method according to claim 8 or 9, wherein the quality of service provision information includes one or more fourth sets of data, each of which relates to quality of service information of the path between a service provider and the sender.
11. A method according to claim 10, wherein the one of more fourth sets of data may be modified according to the characteristics of the preceding link, as it is passed from node to node along the path between a service provider and the sender.
12. A method according to claim 9, 10 or 11, wherein each of said third sets of data and/or said fourth sets of data is concatenated onto the end of the service provision information.
13. A method according to any one of claims 8 to 12, wherein said sender bases its selection of a service at least partly on the received service provision information.
14. A method according to any one of the preceding claims, wherein the network is a wireless ad-hoc network.
15. A method according to any one of the preceding claims, wherein said service provision information and said service requirement information is formatted according to the ETF service location protocol.
16. A service discovery agent for discovering a service provider in a network comprising: means for sending a service request message including quality of service requirement information; means for receiving service reply messages issued in response to said service request message by service providers; and means for selecting a service provider based upon said service reply messages.
17. A service discovery agent according to claim 16 wherein: said means for receiving service reply messages is adapted for receiving quality of service provision information included in the service reply messages and said means for selecting a service provider at least partly bases its selection of a service provider on the received quality of service provision information.
18. A service discovery agent for discovering a service provider in a network comprising: means for sending a service request; means for receiving service reply messages issued in response to said service request message by service providers; and means for selecting a service provider based upon said service reply messages, wherein said means for receiving service reply messages is adapted for receiving quality of service provision information included in the service reply messages, and said means for selecting a service provider at least partly bases its selection of a service provider on the received quality of service provision information.
19. A network device comprising a service discovery agent according to any one of claims 16 to 18.
20. A service provision agent for providing a service in a network comprising: a receiver for receiving service request messages; and means for sending service reply messages including quality of service provision information relating to the service provider, in response to said service request message.
21. A service provision agent according to claim 19, wherein said means for receiving service request messages is adapted for extracting quality of service requirement information included in said service request messages, and further comprising means for determining if the service provision agent meets the quality of service requirements of the quality of service requirement information and controlling the sending of service reply messages accordingly.
22. A service provision agent for providing a service in a network comprising: a receiver for receiving service request messages and for extracting quality of service requirement information included in said service request messages; means for sending service reply messages; and means for determining if the service provision agent meets the quality of service requirements of the quality of service requirement information and controlling the sending of service reply messages accordingly.
23. A network device comprising a service provision agent according to any one of claims 20 to 22.
24. Processor code for carrying out the method of any one claims 1 to 15.
25. A carrier medium carrying computer readable instructions for controlling a computer to carry out the method of any one claims 1 to 15.
26. A network device substantially as described herein with reference to the attached drawings.
27. A method for discovering a service provider substantially as described herein with reference to the attached drawings.