There are several types of ubiQoS components that can distribute on the hosts along the VoD paths:

ubiQoS client stubs, which forward VoD client requests to ubiQoS components and redirect RTP flows to their local visualization tools in a transparent way, to integrate ubiQoS with legacy VoD players. At the moment, we have implemented ubiQoS client stubs for JMF and Mbone vic players.

ubiQoS server stubs, which answer to service requests from ubiQoS components by encapsulating VoD flows from legacy servers into RTP flows transparently. Up to now, we have implemented ubiQoS server stubs for JMF data sources.

ubiQoS proxies, which distribute along the VoD distribution path and perform admission control/reservation for incoming/outgoing flows. They monitor system- and application-level state of local resources and, depending on this information, trigger local QoS adaptation operations. In addition, they coordinate with their previous and next ubiQoS components in the path both in the initial negotiation phase and at provision time when variations in resource availability occur.

ubiQoS gateways, which extend ubiQoS proxies with inter-domain coordination and naming operations. Any service domain contains one ubiQoS gateway (possibly replicated with a master-slave solution). The ubiQoS gateway is the only component in a domain to have complete visibility of neighbor domains and of server/client stubs and ubiQoS proxies within the domain. This helps in scalability of naming resolution and host/domain specific management decisions.

The service provision scenario of Figure 1 shows how the different ubiQoS components cooperate to tailor and adapt the QoS of VoD flows. At negotiation time ubiQoS components dynamically distribute on the hosts along the VoD path. The different QoS requirements of user1 and user2 (and of their access devices) have suggested a high-quality flow to the VoD server and its scaling down at the ubiQoS proxy in domain2. At provision time, in case of degradation of link1 bandwidth, after the coordination of ubiQoS components in domain1 and domain2, the same ubiQoS proxy adapts the VoD transmission for user1 by reducing the frame resolution according to the receiver preferences profile. If there are no resources to adapt QoS by respecting negotiated requirements, e.g., in case of failure of link2, a new VoD path segment can ultimately be established. The ubiQoS gateway in domain3 launches a discovery for a suitable VoD server in its near domains, then negotiates with new ubiQoS-enabled hosts, and finally restarts the flow transmission, from the point in which it was interrupted (if server4 can support random-access to that VoD content). Apart from the time interval to establish the new VoD path, the server swap can be transparent to the receiver and to the other intermediate ubiQoS components.

Let us finally note that in the case of multicast distribution of the same VoD content, the generated network traffic significantly decreases: ubiQoS can verify the presence of multiple targets within the same sub-tree of domain localities, and can split packets only where necessary.

Figure 1. ubiQoS tailoring and adaptation operations in the transmission of the same VoD content with different QoS levels to user1 and user2.

 
Page updated on
In case of problems, or if you find any bug, please contact us.