Download as PDF

The UPnP QoS architecture specifies UPnP services required to support quality of service reservation in environments with limited bandwidth as home networks, and ensuring a satisfied handling of the remaining services currently deployed. This paper describes an open-source implementation of an extended UPnP QoS architecture that provides service oriented systems with a quick response mechanism to assign resources. This system offers two new operational modes; each of them is optimized for a determined environment and improves the efficiency of the specification defined by the UPnP forum. Finally, empirical results are presented which demonstrate such efficiency improvement.

I.     INTRODUCTION

Homenetworks comprise very heterogeneous devices interconnected through a residential gateway (RGW). They interact in a cooperative way to provide the final user with advanced functionality. A characteristic example for this kind of cooperative systems is a multimedia network. Such networks are characterized by media containers, like PCs, multimedia hard disk, etc… that are able to serve their contents. Furthermore, within the home environment there also can exist devices that act as media players, capable of reproducing the content served by the previous ones. TVs, mobile phones, PCs, etc… can be find among this kind of devices.

Due to some differences existing between the capabilities of each of the devices within a home network and the multidisciplinary communication technologies that interconnect them (Ethernet, WiFi, Bluetooth…), a QoS subsystem must be deployed to ensure application driven QoS. Thus, limited devices will not be over flooded with high-definition content that they can not process.

One of the technologies that supports the multimedia environment mentioned above as well as the dynamic properties of the topology of this kind of networks, is the Universal Plug and Play (UPnP) protocol. This protocol is based on servers (devices) that publish their functionality, and clients (control points) that are able to auto-register such services and use them independently of the device typology.

Based on the architecture defined by this specification, the UPnP Forum defines some standards for specific application areas. Two of them are in the scope of this paper: the AV architecture and the QoS architecture. By means of the first one, any multimedia container can share any AV content with any media player attached to the same UPnP network. By means of the second one, the user can be sure that the AV connection will work correctly after the AV subsystem reserves a determined QoS.

                The main requirement of the QoS ensuring mechanisms is to be enough transparent to the final user, in order to go unnoticed. To achieve this challenge, all these systems try to optimize both its functionality and its efficiency. Regarding the functionality, any QoS System has to be accurate when it takes a determined decision. This characteristic is supposed in any well designed system. On the other hand, related to the efficiency, each system will be characterized by a determined throughput depending on its architecture and modus operandi. 

This paper presents an extended model for the QoS architecture defined by the UPnP forum (UPnP QoS Architecture version 2). This extension tries to improve the efficiency of the actual specification regarding the response time to a QoS ensuring operation.

The rest of the paper is organized as follows: the section II provides an overview related to technologies in the QoS field. The section III describes the proposed model in detail and its functioning. Section IV lists some tips about the implementation. Section V provides the experimental results which evidence the improvement in the efficiency that develops the final system. Finally, the section VI summarizes and concludes the contribution of this paper.

II.     Related work

Currently, there exist several initiatives which search to find a QoS system able to optimize both the functionality and the efficiency of this kind of QoS ensuring mechanism. Among them, H. Lee et al. ‎[1]put forward the problem of adapting the UPnP QoS mechanisms to the dynamic variability of some networks while new traffics are allowed. Other authors as M. Ditze et al. ‎[2]emphasize the loss of resources derived from the static reservation strategy (defined by the specification) because some AV applications vary in bandwidth occupation along with the time required to fit to this static pattern. He tries to reduce this effect using a fuzzy logic decision model. Both, H. Lee’s and M. Ditze’s approaches focused on optimizing the allocation of resources, but neither H. Lee nor M. Ditze optimize the QoS subsystem response time.

Closer to the home network field, several works go in the line of the integration of a QoS subsystem into a RGW. N. Goeminne et al. ‎[3]describe a solution to ensure end-to-end QoS by mean of an UPnP deployment over a platform based on the Open Services Gateway initiative (OSGi), very appropriate for programming RGWs. A similar approach presents I. Vidal et al. ‎[4]when showing a platform that extends the TISPAN Next Generation Network with an end-to-end QoS and allows three configuration modes (external, automatic and by the user).

Finally, R. Seepold et al. ‎[5]‎[6]defines a QoS model for multimedia distribution integrated into a RGW over an OSGi middleware. This proposal is based on a modular architecture which divides the QoS system tasks into specialized subsystems.

This paper describes a new model based on R. Seepold‘s proposal. The main idea is to extend the UPnP QoS model, in which it is based, with a persistence system that will maintain locally the state of the network at each moment. Furthermore, the defined QoS subsystem will have several operation modes so that its behaviour can be optimized to different environments according to the stability of the network topology.

III.     Design

This section exposes the implementation of the new system, describing each of its components as well as the new developed features. Next, possible admission control and operation modes which can be configured in the system to perform its role, will be described in more detail.

A.     Extended model

The implemented system takes the specification that has been defined by the UPnP forum and extends it with the following features:

• Extended data model that allows a parameterized description of the requested traffic.
• QoS Manager persistence system. This system is in charge of maintaining both the state of the instantiated flows in the network and the given network topology.

The first extension allows the implemented system to remember the traffic description parameters (like bandwidth, max delay permitted and bit rate demanded) to manage the admission of a new traffic within the network, improving the priority-based admission control that the UPnP forum specification defines. The second feature will allow storing dynamically the network state within the QoS Manager. In this way, it can make use of this information in order to reduce the number of requests to the devices to know this information, improving its efficiency.

The QoS system is divided into three entities that fit in the UPnP QoS Architecture (QoS Manager, QoS Policy Holder and QoS Device). In the following subsections, each item will be analyzed in more detail, describing their internal architectures and how they have been adapted to the new data model and persistence system above described.

1)     QoS Manager

It is the central entity of the QoS system. It is in charge of managing all new traffic request realized by an AV UPnP client and coordinating the activities related to the convention of the quality requirements. Its functionality is based on registering all the QoS Devices located within the local domain, in order to invoke their services whenever it is necessary to ensure the quality in the communication between two devices.

Fig. 1. QoS Manager Architecture

Its architecture is composed by several modules, as it can be seen in Fig. 1. Each one is in charge of carrying out a set of tasks which complete the system functionality. In the following points, these modules and their relationship to other ones are described.

QoS Manager Service:Module that acts as an UPnP device from the point of view of any UPnP client (e.g. AV Control Point). It publishes all services necessaries for instantiating, releasing or updating certain traffics within the UPnP network, redirecting the requests it receives to the QoS Manager Controller. This module implements the interface that will be offered to the external world in order to:

• Check whether it is possible to instantiate a new traffic and if so, to realize the required operations to reserve the resources necessary for the new traffic coursed.
• Release resources reserved by a finished connection.
• Update the resources reserved by a particular traffic whenever it is possible to adapt the resource allocation to the new requirements of the flows.

QoS Manager Ctrl Point:This module implements an UPnP client, being in charge of registering all QoS devices attached to the local network and querying for all services they offers. It acts as a proxy towards the QoS Manager Controller, providing it with the registered UPnP services, so that it can access to the functionality implemented by these devices related with the quality assurance.

Quality Manager Controller:This module can be considered as the QoS Manager’s brain. It orchestrates the interactions between all modules, requesting each one to execute its functionality when an UPnP client (e.g. AV Control Point) tries to instantiate, release or update a determinate traffic

Admission Control:This module is in charge of implementing the necessary routines to manage the admission control of a new traffic in the UPnP network. To do this, it retrieves from the QoS Manager Controller the network characteristics in a determinate moment, and it checks whether it is possible to introduce the new traffic into the network using the traffic specification (bandwidth required, delay supported,…), that the UPnP client has sent within its request. This operation can be complemented by the QoS Devices functionality so that they can refuse or accept the decision the manager has made. In this way, depending on who is involved in the admission process, different admission control modes will be defined (these ones will be in the admission control modes sub sections).

Flow Holder:It is in charge of storing the traffic status with in the managed network. This is connected with the Admission Control module through an interface that allows it to retrieve the resources each device has reserved.

This module completes its functionality using a storage mechanism based on a database. Such database stores the reservations that have been done over the network devices. To do this, the previously mentioned interface also offers to the Admission Control module the necessaries routines for inserting, deleting or modifying the database entries once a determinate traffic has been reserved, released or updated respectively.

Topology Holder:This functional module offers an interface to the QoS Manager Controller so that it can retrieve, on demand, the connection route between two devices as well as the features (at that moment) of each node on the path.

Optionally this module functionality can be based on the existent topology database that stores a relational graph according to the real network. It is composed by virtual descriptions of the features of the QoS Devices discovered as well as their connections points to the reachable interfaces of other QoS Devices. Such topology stored is continuously updated by a background process based on the event published when a new UPnP device is attached to the network. This process will avoid inconsistencies, maintaining updated the network graph. Furthermore, this database maintains the previously configured routes between two devices, so that it is possible to avoid duplicated operations in order to trace a route which connects two devices, saving computational resources and increasing the system efficiency

Therefore, the main functioning of this module can be implemented in the following two ways:

• Distributed:In this mode, the module interacts with the QoS Devices attached in order to retrieve both their features and the path to connect two devices.
• Centralized: This mode is based on the centralized storage of both the network topology and the routes previously calculated. In this way, when it is required to calculate a path, this module checks if this route has been calculated before in order to automatically return it. In other case, the Topology Holder will calculate the required route using the database information.

2)     QoS Policy Holder

This entity stores the policies that include information about priorities, traffic classes and user types which will be used to carry out the admission control of a determinate traffic. This entity has been developed as a basic UPnP Device that implements a set of services. Such services allow the QoS Manager to retrieve these policies.

3)     QoS Device

The QoS Device entity offers the UPnP interface needed to reserve resources in QoS-capable devices. There is one and only one QoS Device for each one of the physical devices attached to the network.

This one is responsible for deciding whether a traffic flow will be accepted or not. The QoS Device saves a list of network interfaces from the device, being aware of the available and busy resources of each one. In this way, when a traffic flow (described by a traffic descriptor) has to be allocated, it will process such request, as well as the resources demanded by it, and will decide if it is possible to instantiate the new traffic or not. Therefore, if the reservation would be possible, the capabilities of such device will be updated in order to reflect the new situation. 

Another function of a QoS Device is to provide the QoS Manager with the information about itself, including connections, capabilities and its current state. This information can be extracted from the device in different ways depending on the platform the device is running on. Among them, the most characteristic ones are:

• By system calls to the OS.
• By invoking middleware services.
• By inference. In this case it would scan and monitor the network interfaces in order to detect any pattern or any statistical estimation of the quality parameter inferred.

Any of the method mentioned above is more or less valid, but usually a combination of them is applied in order to get a better real value estimation of these parameters.

B.     Admission control modes

Admission control is defined as the process to determine whether a traffic flow will be accepted by the QoS subsystem or not. This process is based on the knowledge of both the flows which are currently running and the resources still available within the devices that are involved into the new traffic requested. Once this information is known, both the QoS Devices and the QoS Manager can decide if it is possible to instantiate such new flow or not. 

Depending on which entities intervene into the admission control process, the next two admission modes are defined.

1)     Hybrid Mode

In this case, both the QoS Manager and the QoS Devices takes part in the admission control process. This modus operandi is agreed with the defined by the UPnP QoS specification v2.0. 

Such process is begun by the QoS Manager, which checks the viability to introduce the new flow into the network. Once the decision has been taken, it has to be corroborated by the QoS Devices, which will send its approval or refusal to the petition according to the streams configured into them.

This operation allows the final system to obtain a consistent result, corroborated by all the QoS entities; this is not a duplicated function but a cooperative process where the QoS Manager determines a rough result to a traffic request and the QoS Devices confirm such decision using the real state of the network.

2)     Centralized Mode

This mode shows an extension of the UPnP QoS specification v2.0. In this case the admission control process is exclusively managed by the QoS Manager, so devices that support QoS do not participate in the decision process.

The consistence of the decisions taken by this mode is based on the information that the QoS Manager has got related to the available resources of the network devices. The possibility of taking a wrong admission decision exists in case there was some mistake within the information stored. On the other hand, this methodology allows improving the efficiency of the system as far as the time to response due to the admission control process is concerned.  

C.     Operational modes

The QoS system implementation that has been developed allows configuring three different operational modes in order to adapt its behaviour to the requirements of the environment where it is deployed.

All these modes are activated when the QoS Manager receives a request from a multimedia device for reserving some resources to a traffic flow. At this moment, the QoS Manager queries in Policy Holder for an appropriate policy to be applied to this flow. Once the policy has been retrieved, two design decisions have to be taken into account. The first one related to the particular admission control mode in which the system is operating. The other one refers to the manner of how the necessary information, in order to take a decision about the admission of a particular traffic stream, is retrieved. As it has been described above, this information can be obtained in two ways:

• Asking the QoS Devices.
• Using the persistence mechanism that implements this new system.

Depending on which option has been checked for each design decision, a different operational mode will be configured, so that the final system will show determined features and a particular behaviour, more or less suitable to a determined environment. The three configurable modes into the developed system are:

1)     Basic mode

The basic mode shows a behaviour equal to the UPnP QoS Architecture v2.0. In this mode, both the QoS Manager and QoS Devices participate in the admission control process. In other words, the admission control mode is tuned to hybrid. Regarding the recovery of necessary information, neither the topology database nor the Flow Holder use its persistence mechanism to inform the QoS Manager about the data necessaries to take any admission control decision. Therefore, such information about the network status and interconnections has to be dynamically retrieved from the QoS Devices (Fig. 2).

Fig. 2. Sequence diagram for basic operational mode.

In this way, when any traffic request is received by the QoS subsystem the Topology Holder module, acting in a distributed way, initializes an iterative process asking all QoS Devices in the network for the information about its traffic and their resources status, as well as its interconnections with other devices in order to retrieve the path that interconnects the source with the sink.

This option develops the most robust but the least efficient operational mode. Its robustness is derived from the distributed data acquisition, so that it is not vulnerable to possible mistakes in the data stored into the QoS Manager, and from the cooperative admission control process between the QoS Manager and the QoS Devices, avoiding any wrong decision and supplying more robustness to the final system. On the other hand, this data acquisition and admission control modes makes that the efficiency decreases.

2)     Interactive mode

This operational mode improves the features of the previous one. Like the basic mode, in this case it is also configured a hybrid admission control, where both QoS Manager and QoS Devices cooperate in the admission task. The improvement comes from the usage of the persistence system that stores the state of the flows instantiated into the network, the network topology, and the routes previously calculated. So Topology Holder and Flow Holder modules provide the information required by the QoS Manager in order to do the admission control, accelerating the whole decision process.

The sequence diagram (Fig. 3) shows the operation scheme. On the QoS Manager side, the Topology Holder provides the Admission Control module with the features of the devices which belong to the connection path demanded, using the information it has stored within the database.

Fig. 3.Sequence diagram for interactive operational mode.

On the other hand, the Admission Control module requests to Flow Holder, which will offer information about the current situation of the relevant devices regarding the flows they have instantiated. Once all this necessary information is retrieved,   the admission control process is carried out into the QoS Manager, checking whether the new traffic requested is viable or not. If such viability is confirmed, the QoS Devices admission control mechanism is invoked by the QoS Manager to confirm the decision. Only after successful completion, the QoS subsystem accepts the traffic flow. In this case the Admission Control module will store the new instantiated flow into the flows database using the Flow Holder module.

The problem of this operational mode could appear when inconsistent information regarding the real status of the network is stored into the database. One of the scenarios where this problem can occur would be characterized by more than one QoS Manager in the same home network. In this case, the devices attached to the network will be controlled by all the QoS Managers. Because of that, databases of each QoS Manager do not reflect the changes caused by other QoS Managers, while the QoS Device associated to such device does it. These circumstances and many similar others would produce inconsistent in the QoS Manager persistence system.

These kind of situations are solved by this operational mode, so that the hybrid admission control mode consults the QoS Devices when any flow reservation has to be done,  as it has been described above, avoiding to take a wrong decision.  

3)     High-efficiency mode

This operational mode is the most efficient one as it will be tested in the experimental results section. Its behaviour is similar to the interactive mode, but in this case the admission control mode is tuned to centralized, being only allocated in the QoS Manager. Furthermore, as in the previous mode, the persistence system is used in order to retrieve the features as well as the flows reserved into the devices.

This operational mode increases the efficiency by eliminating the interaction between the QoS Manager and the QoS Devices, so that the manager only uses the information it has stored within its databases.

On the other hand, this mode is the most vulnerable, because a mistake in the data stored into the QoS Manger would be able to have serious repercussions in the admission control process, accepting traffics which cannot be allocated into the network or refusing viable ones. Anyway, such mistakes are not very common. Therefore it can be said that this mode is the most suitable configuration in a standard scenario, due to its efficiency and relative accuracy.

IV.     Implementation

The implementation of this new QoS architecture has been developed with the Eclipse 3.3.1.1 environment, using Java as programming language. It has been necessary to use the Java Virtual Machine version 1.6, because only it provides some required routines to retrieve the devices features information.

The required databases have been implemented using SQLite version 3.5.6. This database manager has been selected in order to achieve the balance between a satisfactory throughput and a small footprint. This will facilitate the integration in small portable devices.

Regarding the UPnP environment, the UPnP protocol stack implemented by Ciberlink  has been used, developing both the UPnP control point and devices that compose each entity of the complete QoS subsystem over this stack.

V.     Experimental results

In order to test and determine how each of the operational modes of this implementation contributes to the efficiency, a generic scenario has been built. It consists of a LAN with several PCs executing different UPnP services. Inside this scenario, the QoS system defined in this article has been deployed in order to secure the QoS into the network. In this way, there is a QoS Device associated to each mentioned PC, while a QoS Manager and a QoS Policy Holder has been installed in a RGW that manages such LAN.

To test the features of each operational mode, 500 calls for traffic reservation have been done, measuring the time elapsed from the invocation moment until the operation finishes, and later statistically analyzed.

To carry out the improvement study, it has been measured the percentage of time that a model saves with regard to another one. In other words, this parameter will show how much time is saved by the mode under study over the time needed by the reference model to finish the same action. To do a perfect characterization of the improvement introduced by extension proposed in the article, it has been considered the basic mode as reference, analyzing the behaviour of the other ones regarding it.

Table 1.General summary of the results for request respect of each operational mode,

Under this scenario the testing process registers for the basic mode a mean delay of 679.71 ms to configure only one flow. Analyzing the others modes features it can be seen that under the interactive and high-efficiency modes, strong improvements are obtained. In the first case, as it is shown in Table 1, the improvement takes a value of 56.44 % and in the second case, it is 62.86 %. This data implies that the two new modes add high improvement to the QoS subsystem.

The new QoS Manager operational modes accelerate the traffic reservation process thanks to the local storage of the network state by using the Topology Holder and the Flow Holder. The statistical analysis shows that the high-efficiency mode provides the best improvements with respect to the response time to a QoS reservation request. Since each change of the current flow status needs to be tracked or negotiated, those new models help to reduce time for negotiation and establishment of new flows. In case of an increasing number of devices in the network or an increasing number of devices participating in the QoS reservation process, the efficiency will further increase. Furthermore, as many network calls are saved, the bandwidth is not decreased because of the QoS subsystem operations. This advantage is mainly exploited by the high-efficiency mode. This can be easily applied in mainly semi-static topologies which do not frequently change so it applies well to home networks.

To complete the statistical analysis, the basic mode produces a standard deviation (SD) of 73.70 ms that involve the 10.84 % of the mean of the delay time, and the interactive and high-efficiency modes presents a SD near to 30 %. In spite of a lower SD is desirable because it means that the model is more stable and predictable, the increase of the delay due to the fluctuation in both interactive and high-efficiency modes continuous lower than the decrease produced because of the same reason in the basic model.

VI.     Conclusion

In this work, a complete and extended model of the UPnP QoS Architecture has been implemented. Two new operational modes instead of the supplied by the specification are described and analyzed from both conceptual and quantitative points of view. Positive results in the experimental process have been obtained and this underlines that the new model has the capability to increase the efficiency of the QoS subsystem and to reduce its response time. Therefore, the subsystem suggested in this paper shows an efficient system that improves QoS system defined by the UPnP Forum.

ACKNOWLEDGMENTS

The work has been partly funded by the projects Caring Cars (MEDEA+ 2A403) (Spanish Ministry of Industry, Tourism and Commerce; FIT-330215-2007-1), PLANETS (MEDEA+ A121) (Spanish Ministry of Industry, Tourism and Commerce; FIT-330225-2007-14), MUSE (FP6 26442) and InCare (Spanish Ministry of Education and Science; TSI2006-13390-C02-01).

REFERENCES

• H. Lee, S. Moon, J. Kim, “Enhanced UPnP QoS Architecture for Network-adaptive Streaming Service in Home Networks”, IEEE Transactions on Consumer Electronics, Vol. 53, No. 3, Aug. 2007.
• M. Ditze, M. Grawinkel, “Fuzzy Logic Based Admission Control for Multimedia Streams in the UPnP QoS Architecture”, Proceedings of the 21st International Conference on Advanced Information Networking and Applications Workshops, Vol. 01, 2007.
• N. Goeminne, K. Cauwel, F. Turck, B. Dhoedt, “Deploying QoS sensitive services in OSGi enabled home networks based on UPnP”
• I. Vidal, J. Garcia, F. Valera, I. Soto, A. Azcorra, “Integration of a QoS aware end user network within the TISPAN NGN solutions”, IEEE 4^th European Conference on Universal Multiservice Networks (ECUMN2007), Feb. 2007.
• R. Seepold, N. Madrid, J. Fernández,  “QoS Management for Distributed Multimedia Services”, IFIP/IEEE International Conference on Management of Multimedia and MobileNetworks and Services (MMNS 2007).
• R. Seepold, J. Fernández, N. Madrid, ”Multimedia Service Management for Home Networks with End to End Quality of Service”, Asia-Pacific Network Operations and Management Symposium (APNOMS 2007).