Admission Control and Drop Strategies in a UPnP ... - Semantic Scholar

Admission Control and Drop Strategies in a UPnP-QoS Controlled Home Network Vincenzo Suraci†

Guido Oddi††, Nico Mattiacci, Andrea Angelucci

Università degli studi e-Campus Novedrate, Italy † [email protected]

Dipartimento di Informatica e Sistemistica (DIS) Università di Roma “Sapienza” Rome, Italy †† [email protected]

Abstract— The spread of novel multimedia services such as audio and video streaming, HDTV and online gaming have become a ordinary in the home networks. Therefore, the possibility to manage the Quality of Service (QoS) within an home environment becomes a crucial factor for the satisfaction of the user. In this paper we propose an enhanced Admission Control and Drop strategies for a UPnP-QoS controlled home network to guarantee QoS for multiple concurrent services. The UPnP-QoS architecture works well in the case of moderate traffic loads, but may fail whenever the network becomes overloaded. The paper demonstrates how the combined use of the proposed admission control and drop solutions with the UPnP-QoS framework avoids network congestion and guarantees QoS to all the admitted traffic streams. A proof of concept Java implementation has been developed to demonstrate the expected results in a real home environment. Keywords: Heterogeneous Home networks, QoS Management, UPnP-QoS, Admission Control, Traffic Dropping, Preemption

I.

INTRODUCTION

Over the last few years the market for home networks has been increasingly developed by the constant request of customers for services featured by tangible qualities: speed, reliability and plug and play connectivity. Modern home networks are generally characterized by devices communicating with each other by means of various technologies, forming a heterogeneous environment. Many applications, such as VoIP and audio-visual streaming, are strongly sensitive to end to end delay, jitter and loss experienced by the associated packet flows. Without any packet marking, the Internet Protocol (IP) does not provide any kind of quality of service (QoS) to the applications, offering only best effort service. The possibility to manage in a plug and play fashion the QoS within an IP-based home environment becomes a crucial factor for the diffusion of novel added value services. Indeed such services, which an end user generally pays for, cannot rely on best effort networks. A first milestone in the home networks convergence has been achieved by the FP7 EU OMEGA project, which introduces a technology independent convergence layer: the Inter-MAC layer [15]. In [4] the Inter-MAC is presented as a 2.5 layer located between the IP and the MAC/LLC layer that provides Quality of Service over heterogeneous networks in a home environment. Inter-MAC supports three different classes of service (low latency, real time and elastic) and provides a

double translation mechanism: map the higher layer QoS requirements into the correspondent Inter-MAC class of service and map it into the classes of service provided by the underlying MAC technologies. Unfortunately the Inter-MAC has not been yet standardized so such a promising technology cannot be currently exploited to provide transparent QoS over dissimilar technologies. A promising middleware-based framework capable to seamlessly manage the QoS in home environments has been designed by the Universal Plug and Play (UPnP) forum. The standard UPnP-QoS v3, presented in [1], takes advantage of the capabilities of UPnP framework and defines a set of services aimed at guaranteeing Quality of Service in heterogeneous home networks. UPnP is widely used in home networks [2] and supported by a large number of networked devices (e.g. set top boxes, home gateways, game consoles, printers). UPnP represents an incredible driving force towards the global adoption of UPnP-QoS v3 framework: such a framework, however, has not yet the same success of UPnP, it needs to be refined and extended in order to be adopted as a standard de facto in QoS-aware home networks. While convergence and Plug and Play Quality of Service in home networks seems to be still evolving research fields with many unresolved issues, the different home network architectures proposed by several research teams (HGI, IEEE, ETSI, ITU) have a common point: the presence of the Home Gateway. Whatever home network model will succeed in the incoming years, the role played by the home gateway will be more and more important for a home environment. The home gateway must be equipped with agile operating systems able to follow the evolution of home technologies and services. With respect of home gateway frameworks, OSGi [3] is a promising lightweight software agent providing standardized primitives that allow home gateway applications to be constructed from small, reusable and collaborative components. In the light of the above considerations the combined use of a QoS Plug and Play middleware (UPnP-QoS) within a home network equipped with an agile home gateway (OSGi) enables the network to provide seamless QoS configuration and next generation services support. In order to allow transparent management of traffic streams, this article proposes an improvement of UPnP-QoS intelligence, especially regarding admission control and traffic drop functionalities. The admission control technique decides to accept or reject a new traffic flow on the basis of flow priority (TrafficImportanceNumber), QoS requirements and the current network load. A

drop function is in charge of applying pre-emption techniques, with the objective of freeing precious network resources dropping lower priority traffics. The paper is organized as follows: Section II introduces the UPnP-QoS framework. Section III describes the UPnP-QoS home network architectural model. Section IV illustrates the improved Admission Control and Dropping algorithms proposed in this article. Section V provides implementation details of the proof of concept demonstrator. Section VI describes the test-bed scenario and Section VII shows the achieved results. Section VIII concludes the paper with the advantages of the proposed solutions and with proposes some possible future works. II. THE UPNP-QOS FRAMEWORK The UPnP-QoS framework is a standard specification, based on UPnP, a set of networking protocols situated at middleware layer, capable of performing QoS setup of traffic streams to be executed in single IP subnet. It supports QoS management in the IP subnet for traffic streams originating from or terminating outside it. The goals of UPnP are to allow devices to seamlessly connect and communicate and to simplify the deployment of networks in the home and in corporate environments. Two types of devices are defined within the UPnP architecture: controlled devices (or simply devices), and control points. A controlled device acts as a server responding to requests from control points. Each device exposes a set of services, and each service includes a list of commands, or actions, to which the service responds, and parameters, or arguments for each action. UPnP-QoS defines three UPnP services: the QosPolicyHolder service [5], the QosManager service [6] and the QosDevice service [7]. The QosPolicyHolder service is a repository of QoS policies for the UPnP network. The QosManager service defines a set of actions for a Control Point to setup, release, and update the Quality of Service for a requested traffic stream. In a network with admission control, the role of the QosManager is to admit a traffic stream to the network on the basis of the traffic stream’s requirements and the current network load. It interacts with all network elements by means of the QosDevice services deployed on them. The QosDevice service is implemented in a source, sink or intermediate network device and is responsible for managing the resources connected to the device. III. UPNP-QOS NETWORK MODEL The UPnP-QoS framework defines a traffic stream as a unidirectional flow starting from a source device towards a sink device, possibly passing through intermediate devices. The admission control and the drop modules, situated inside the QosManager service of the network, coordinate all the network devices (by means of QosDevice services deployed on them). In order to facilitate the comprehension of the whole article, the following UPnP-QoS fundamental concepts are introduced: Interfaces and Links: devices are connected to a single mono-technological sub-network by means of a physical interface (e.g. an Ethernet network card). A link is a (possibly bidirectional) direct connection between two devices (more precisely the distinct interfaces belonging to the devices) for data exchange. An interface can be involved in multiple links.

Within a specific device, a link can be associated to only one interface. Path: UPnP-QoS framework manages the Quality of Service of a traffic stream that flows between a source and a sink device. The flow path (composed by a sequence of QosDevice services through which the flow passes, as shown in Figure 1) is determined on the basis of the path information supplied by each QosDevice service to the QoSManager. Using such information, the QosManager composes the path and proceeds to the Quality of Service setup. QoS Segment: a QoS Segment is the (sub)set of QosDevice service’s interfaces that are under a single Admission Mechanism (e.g. a single Wi-Fi network with a single central responsible coordinator). An identifier, the QosSegmentId, univocally characterizes each QoS Segment. Such an identifier is generated accordingly with the rules defined in the QosDevice Technology Addendum [8].

Source QosDevice

Sink QosDevice QoS Segment A

Bridge A QosDevice

QoS Segment C

QoS Segment B

Bridge B QosDevice

Figure 1: Path Determination Example

In Figure 1 each network device hosts a QosDevice service (end devices and intermediate bridges). For such a reason the path can be completely determined since each node is able to supply path information. Oppositely, if any of the two bridges do not host a QosDevice service, then the QosManager can consider just the parts of the path that can be determined (e.g. QoS Segment B is not under QosManager control). Therefore, the central QoS Segment cannot be managed in any way. In this paper we did the assumption that the QosManager has a full knowledge of the network topology. IV. ADMISSION CONTROL AND DROP The use of prioritization schemes aim at discriminating the quality of distinct traffic flows by means of specific priority class tagging values. In critical situations (e.g. available bandwidth leakage) only few flows experience an acceptable degree of QoS with the detriment of low priority traffic flows, which are heavily degraded. Oppositely the application of admission control policies allows to perform a prior analysis of the network load in order to verify whether a new traffic flow can be accepted or not. In case of rejection, at least one QoS Segment in the source-destination path cannot admit the flow without degradation. Jointly with the admission control, a drop policy can be invoked in order to appropriately identify, among all the current running traffic flows, one or more to be preempted with the lowest possible cost, as accurately explained in the subsections. A. Admission Control Algorithm Once the QoS Manager service receives an admission request regarding a new traffic flow willing to access the network, the admission control algorithm requests bandwidth

information, namely the Rotameter Observation (RO), to each QosDevice service in the source-sink path. Define ROs as the amount of used bandwidth for each QoS Segment s crossed by the path. For each of these segments, the admission control algorithm determines the remaining bandwidth Rbs, on the basis of the Rotameter Observation collected for such a QoS Segment. The calculation of the remaining bandwidth depends on the physical technology characterizing each QoS segment1 (i.e. 802.11x, 802.3, Homeplug AV, etc.). Do not use the estimation of MaxPhyRate and ListOfAdmittedTraffic because not allows to regard the resources used by those flows, in the home network, that have not requested QoS. Let S = s1, … ,sn be the QoS segments set in the path, and let Tbs be the maximum bandwidth of QoS segment s. For each segment in the path, the remaining bandwidth Rbs can be calculated as Rb s  Tb s  RO s . If on every QoS Segment belonging to the path, the remaining bandwidth Rbs is greater than the data rate Dr declared in the Traffic Specification (TSPEC) of the new admitting flow, then the admission control algorithm accepts such a flow. Oppositely, if one QoS segment does not have enough resources to admit the new stream, the admission control algorithm invokes the drop procedure. B. Drop Algorithm The drop algorithm is invoked by the admission control. It takes as input the set (Nt) of all traffic currently executing over the network and the set of QoS Segments (Sf) that the admission control algorithm has determined to have not enough available resources to let the new flow being admitted. As a first step, the drop algorithm performs a filtering on the Nt set, generating a new set of flows (Ntf). The flows which have higher priority and which do not pass through any QoS segments in the Sf set are filtered. As a second step, the drop algorithm examines each traffic t  Ntf with the aim of determining the amount of bandwidth on each QoS Segment that could be potentially obtained if traffic flow t was chosen to be dropped. Obviously, the dropping action has an effect on all the QoS segments through which that traffic flow passes, hence also on QoS Segments not belonging to Sf. For this reason the drop algorithm maintains the information on the amount of bandwidth freed by the preemption operation, for all the QoS segments. The choice of associating a cost to each dropping solution is driven by the fact that each preempted flow represents a loss for the network and therefore a negative event. The idea is to reasonably drop the less important flows to admit more important flows. The third step of the drop algorithm represents the core of the procedure: such a phase consists on the execution of a recursive method that visits all the possible dropping combinations of running flows t  Ntf in order to find which flows are the best candidates to be preempted. For each combination c of traffic flows, an admissibility value and cost are computed. The admissibility value is a boolean value which is true if by dropping the traffic flows contained in c, an

amount of bandwidth sufficient to guarantee the admission of the new traffic flow can be released, and false otherwise. If the admissibility value is true, the related cost is calculated. The cost is computed product between the released resources (Rr), beyond those necessary for the entrance to the new traffic (Dr Rbs), and the sum of the Traffic Importance Number (TIN) values of all traffic flows accounted in the combination c. Described formally as follows: Cost c   ( Rr s  ( Dr  Rb s )) / K   TIN t with K nors S

tc

malization constant. The TIN is a UPnP-QoS integer value that represents the priority associated to that flow. Taking into account the TIN values of the traffic flows, a higher cost is given to dropping solutions that release traffic flows with higher priorities. This procedure aims to assign less cost to low priority traffic flows and to preferably drop flows which do not under-utilize network resources. The solution of the algorithm consists in an admissible combination of flows c* with the lowest cost. The recursive method visits all the combinations of traffic flows by creating a tree as shown in Figure 2. Each node of the tree is boolean string. In the shown example, three potential flows can be dropped, thus three boolean values identifies uniquely a drop combination. Each element of the binary string indicates whether the single flow univocally determined by its position within the string is considered or not to be preempted by the related dropping solution. 0–0–0

1–0–0

1– 0 – 1

0–1–0

1– 1 – 0

0–1–1

0–0–1

Not admissible Admissible Not optimal

1– 1 – 1

Figure 2: BFS on the drop algorithm tree

The dropping tree is visited using a breadth-first-search (BFS): such a choice allows to limit the exploration of the tree. If a parent node of a sub-tree is already an admissible solution (combination 1-0-0 in Figure 2), exploring the sub-tree leads only to higher cost solutions that will be necessarily discharged by the drop algorithm. The computational complexity of the drop algorithm depends on the total number of nodes m. In our case, the total number of nodes is equal to the total number of possible combinations of concurrent traffic flows. If the number of such flows is n, then the number of combinations is m=2n. Therefore, the computational complexity of the tree is O(2n). Although such a value leads to an exponential complexity in the case of home network, it does not affect the overall computational performances, because the total number of concurrent QoS aware traffic flows is limited.

1

The compute of the remaining bandwidth is based on MaxPhyRate of physical technology characterizes the QoS segment and the Rotameter Observation of QosDevice(s) which constitute the QoS segment.

V. IMPLEMENTATION The programming language used to implement the UPnPQoS framework and the algorithms proposed in this article has been chosen with the aim of creating a portable framework. For

such a reason Java programming language represents a valid choice. The implementation of UPnP-QoS framework has been carried out over an existing open source UPnP library, namely Cyberlink [9]. The UPnP and UPnP-QoS frameworks have been designed and developed in compliance with the OSGi paradigm. In our test-case we choose the java based, open source Knopflerfish implementation of OSGi [10]. Figure 3 shows how the UPnP and UPnP-QoS frameworks have been deployed in the OSGi environment. The Upnp-LIB bundle is a library bundle containing the UPnP framework and its fundamental blocks (e.g. device, service, action, control point). The UpnpQoS-LIB bundle uses Upnp-LIB in order to implement the UPnP-QoS services, specifically the QosManager, QosDevice and QosPolicyHolder services, along with the intelligence associated with them. Finally, UpnpQoS Media Client and UpnpQoS Media Server represent a clientserver media application, used to setup flows with a specified Quality of Service. The UPnP QoS libraries, media client and media server have been implemented in compliance with the detailed specifications provided by the UPnP-QoS v3 standard.

Upnp-LIB Upnp-LIB

UpnpQos-LIB UpnpQos-LIB

UpnpQos UpnpQosMedia Media Server Server

UpnpQos UpnpQosMedia Media Client Client

Figure 3: OSGi bundles relations.

The available bandwidth estimation requested by the admission control and drop algorithms requires methods to monitor the link state of the connected devices. The admission control algorithm needs to collect information concerning the status of device interfaces, including the number of sent and received packets, differentiated by the priority class as well as the flows to which such packets belong to. The admission control algorithm obtains such information invoking the GetRotameterInformation() methods exposed by the QosDevice services resident on the nodes belonging to the source-sink path. An accurate implementation of GetRotameterInformation() is essential to make the whole admission control strategy to work properly. The network monitoring functionalities have been introduced in the QosDevice Java implementation using the jNetPcap open source library [11]. jNetPcap provides a Java wrapper for the libpcap library for network packets capturing. In order to guarantee portability of our framework in Windows-based and Linux-based operating systems, jnetpcap.dll library and libjnetpcap.so library are used to cover both the cases. The monitoring module inside each QosDevice service manages several threads: one for each network interface card attached to the machine. Each thread is in charge of capturing packets being transmitted through a specific network technology. Each packet is examined to determine its size, the traffic flow to which it belongs to and its traffic class. The collected information are then adapted in a RotameterObservation structure as defined by UPnP-QoS v3 specification [7].

Once the RotameterObservations are collected and the admission control algorithm is executed, in case of flow admission the AdmitTrafficQos() action is invoked on all QosDevice services exposed by source-sink path nodes. Conversely, the drop algorithm is invoked in order to determine one or more flows to be pre-empted. The drop algorithm finds the lowest admissible cost solution, or returns a negative response whether no admissible solution can be found. If a feasible solution exists, the ReleaseTrafficQos() action is invoked on the QosDevice services associated to the list of dropped traffic flows. Once the flows have been dropped, the AdmitTrafficQos() can be invoked by the QosManager on the QosDevice to admit the new flow over the source-sink path. VI. TEST ENVIROMENT The nodes deployed in the test-bed environment consist of Media Server nodes and Media Client nodes. The Media Server hosts a UPnP Media Server service, a QosDevice service, a QosManager service and a QosPolicyHolder service. The UPnP Media Server service provides an interface allowing to manage a list of movies providing the possibility to show the list of available multimedia sources and to start their streaming. The streaming flow between a Media Server node and a Media Client node has been implemented using the Java Media Framework (JMF) [12]. The test-bed environment consists of a home network comprising four computers (three Media Client and one Media Server). As shown in Figure 4, the Media Server node is connected to an Ethernet/Wi-Fi bridge through a Fast Ethernet cable and the Media Client nodes are connected through the Wi-Fi 802.11b. The embedded Wi-Fi access point is equipped with WiFi Multimedia (WMM) extension [14] to prioritize traffic. UPnP-QoS divides the home network into two distinct QoS Segments i) a Wi-Fi segment to which the Media Client devices are connected and ii) an Ethernet segment to which the Media Server is connected to. The media files used in the testbed use a variable bit rate (VBR) codec with an average data rate of 1.75 Mbps. Have been realized two scenarios, in which each client requires one or more video trying to saturate the segment Wi-Fi. Where: Scenario 1 - aims at showing the QoS performances obtained adopting the UPnP-QoS prioritization technique without taking advantage of the proposed admission control and drop algorithms. Scenario 2 - aims at showing the QoS performance enhancements achieved by using the proposed admission and dropping procedures in a UPnP-QoS framework.

a) 1 2

3

4

5

6

7

8

ETH

Server OS: Windows XP Services: • Upnp MediaServer • QosManager v3 • QosPolicyHolder v3 • QosDevice v3

WI-FI

Node A OS: Windows XP Services: • Upnp MediaClient • QosDevice v3

Node B OS: Windows XP Services: • Upnp MediaClient • QosDevice v3

Node C OS: Windows XP Services: • Upnp MediaClient • QosDevice v3

b)

Figure 4: Test-bed environment

In the Scenario 1 a single flow can be fully characterized by its priority class. In Scenario 2, the RequestTrafficQos() action exposed by the Media Server node requires a Traffic Specification (TSPEC) structure to admit or reject the media streaming flow. The TSPEC structure must describe at least the bandwidth requirements for a correct streaming. VII. RESULTS This section analyzes the performance results achieved for the deployed traffic flows, especially focusing on Wi-Fi QoS Segment, representing the bottleneck of the proposed home network scenarios. A. Scenario 1 – Prioritized Case Figure 5 shows the temporal sequence of the flows running in the home network, showing the effect of prioritization on the performance of the single flows. As described in Figure 5.a, the initial three streaming flows (towards node A, node B and node C respectively with priority class 0, 7 and 0) easily share the available physical bandwidth in equal parts regardless of their priority classes. The admission of the fourth stream, at time 4, towards node C with priority class 0, leads to the saturation of the Wi-Fi bandwidth with correspondent degradation of video rendering quality of the first blue-lined flow. At time 5, node C requests the execution of an additional video flow (with priority 0) that degrades even more the blue-lined flow towards node A (also with priority 0). The high priority streaming flow directed towards node B experiences a good throughput profile as clearly shown in Figure 5.a (the black-lined flow profile). In the following, at time 6,7 and 8 other three flows are admitted towards node C. This situation compromises the quality of service of all the low priority flows.

Figure 5: Scenario 1: a) Throughput profiles of the admitted flows towards the various nodes: Node A (blue-lined with priority class 0), Node B (black-lined with priority class 7) and Node C (red-lined with priority class 0). b) Total WiFi Bandwidth utilization.

B. Scenario 2 – Admission Control and Drop Three streaming flows start directed to the node A at time 1, to the node B at time 2 and to the node C at time 3. These flows have respectively priority classes 3, 5 and 0, as shown in Figure 6. The admission control algorithm checks, for every admission request, if the bandwidth necessary to admit the new streaming flow is available in all QoS Segments of the sourcesink path: the three requests are admitted, exploiting the same amount of bandwidth, similarly to Scenario 1. Once, at time 4, node C requests for the admission of a new traffic flow with priority class 7, the admission control algorithm checks whether the available bandwidth on all the involved QoS Segments in the path is enough to host the new flow. Since the bandwidth occupied by the already admitted streams is close to the maximum effective bandwidth of the Wi-Fi technology, the admission of the new traffic would lead to saturation (as in scenario 1). Therefore, the admission control algorithm invokes the drop algorithm with the aim to find the best solution. The minimal cost solution is evaluated by the drop algorithm: it consists in releasing the streaming video directed to node C with priority class 0. Figure 6.c illustrates the flow dropping at time 4, and the new admission, with priority class 7, at time 5. Thanks to the capabilities of the admission control and drop procedures, the Wi-Fi saturation is avoided and the quality of running streaming flows is always guaranteed. Oppositely, in the prioritized scenario 1, all flows have been admitted but only the higher priority class streaming flow experience an acceptable quality of service. At time 6, node C requests for the admission of another video stream with priority class 1. The admission control algorithm reveals the possible saturation and calls again the drop algorithm.

a) 1

2

3

4 5

6

7 8

prioritization scenario and an advanced UPnP-QoS Manager equipped with admission control and drop procedures. In case of network congestions, the combined use of flow admission control and drop procedures guarantee QoS better than prioritized networks, independently by the adopted prioritized network technologies. ACKNOWLEDGMENT

b)

c)

The research leading to these results has received funding from the European Community’s Seventh Framework Programme FP7/2007-2013 under grant agreement n°213311 also referred as OMEGA. Also, this project, has been partially supported by the Italian National Project: Wireless multiplatfOrm mimo active access netwoRks for QoSdemanding muLtimedia Delivery (WORLD), under grant number 2007R989S. REFERENCES [1] [2]

d)

[3] [4]

[5] [6] Figure 6: Scenario 2: a) Throughput profile of Node A. b) Throughput profile of Node B. c) Throughput profile of Node C. d) Total Wi-Fi Bandwidth utilization.

In this case the drop can not find an admissible solution, because the currently running flows have higher priority classes. The admission process fails and the flow is rejected. At the end, the node C, at time 7, requests the setup of a new flow with priority class 5. Consequently, the drop is able to find a solution, by releasing the traffic flow towards the node A with priority class 3. VIII. CONCLUSIONS This paper has investigated the QoS capabilities of the UPnP-QoS architecture and highlighted the intrinsic limits due to network overloads consequent to the presence of bottlenecks. The aim of the work is to introduce a feasible approach to the QoS management in home network, proposing combined admission control and drop algorithms. To demonstrate the concepts, a Java implementation of the whole architecture has been proposed. Finally, a test-bed has been deployed comparing two scenarios: standard UPnP-QoS

[7] [8]

[9] [10] [11] [12] [13] [14]

[15]

Members of the UPnP Forum, “UPnP-QoS Architecture:3”, 2008, upnp.org/specs/qos/UPnP-qos-Architecture-v3.pdf. Members of the UPnP Forum, “UPnP Device Architecture 1.1”, 2008, upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf. OSGi Alliance, “OSGi Service Platform Core Specification”, Release 4 Version 4.2, June 2009 V. Suraci, F. Delli Priscoli, M. Castrucci, G. Tamea, W. De Vecchis, G. Di Pilla, “Inter-MAC: Convergence at MAC layer in Home Gigabit Network”, ITC Mobile Summit, Stockholm, 2008. Members of the UPnP Forum, “UPnP-QosPolicyHolder:3”, 2008, upnp.org/specs/qos/UPnP-qos-QosPolicyHolder-v3-Service.pdf. Members of the UPnP Forum, “UPnP-QosManager:3”, 2008, upnp.org/specs/qos/UPnP-qos-QosManager-v3-Service.pdf. Members of the UPnP Forum, “UPnP-QosDevice:3”, 2008, upnp.org/specs/qos/UPnP-qos-QosDevice-v3-Service.pdf. Members of the UPnP Forum, “UPnP-QosDevice:3 Underlying Technology Interface Addendum”, 2008, upnp.org/specs/qos/UPnP-qosQosDevice-v3-Addendum.pdf. S. Konno, “Cyberlink: Development Package for UPnP Devices for Java”, cybergarage.org/cgi-bin/twiki/view/Main/ CyberLinkForJava. Makewave, “Knopflerfish universal open source OSGi Service Platform”, knopflerfish.org/. Sly Technologies, jnetpcap.com/. Sun Microsystems, ”Java Media Framework (JMF)”, java.sun.com/javase/technologies/desktop/media/jmf/. IEEE Standards Electronic, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications “ , 2000. Wi-Fi Alliance, “Wi-Fi Certified for WMM - Support for Multimedia Applications with Quality of Service in Wi-Fi Networks”, September 2004. M. Bellec, J.P. Javaudin, White Paper: “Inter-MAC concept for Gbps Home Network.”, ict-omega.eu/publications/white-paper.html.