The QoS Adaptation module is commanded by the QoS manager with the goal to maintain the negotiated QoS point. Adaptation exploits JMF de/multiplexers, codecs and renderers, together with a set of Java-based transcoding components developed within the ubiQoS project. For instance, we have designed and implemented a family of ad-hoc codecs to convert several VoD input formats into MPEG flows with quality parameters specified at runtime. In addition, the module maintains buffers for current VoD flows to respond timely to incoming client requests in its locality and to pre-fetch the transcoding of served flows when needed. For any VoD flow, the adaptation module locally stores the version received with the best QoS according to the local cost function.

Discovery and directory provide different naming solutions suitable for achieving different goals. They differ in visibility scope (respectively, local vs. global), flexibility (rigidly predefined and simple structure vs. flexible content and organization), and performance (limited low-level efficient protocols vs. complete high-level searching/registering operations), and their differences motivate their integration in ubiQoS. LDAP-compliant directory servers store globally accessible information such as CC/PP user/terminal profiles. Jini-based discovery lookup servers permit to access the subset of VoD contents and ubiQoS elements (client/server proxies, components and gateways) available in any single domain locality. ubiQoS gateways implement both directory and discovery server-side operations. Profiles are only partially replicated on any gateway, and requests for non-locally profiles are forwarded to neighbor gateways. The discovery lookup also runs within the ubiQoS gateway, but discovery clients in the locality do not need to be aware of its location. Other ubiQoS components only implement lightweight client functionality and interrogate the modules for discovery and directory of the ubiQoS gateway in their locality. For fault-tolerance sake, they are automatically redirected to secondary gateways in neighbor domains in case of primary gateway failure.

The ubiQoS middleware is implemented in terms of Java-based SOMA agents and exploits the SOMA modular set of APIs to support mobility, communication, naming, monitoring, security, and interoperability.

A peculiar aspect of ubiQoS is the possibility to exploit the code/state migration typical of the Mobile Agent programming paradigm to improve the dynamic determination of the active path from client to server and to re-arrange it at service provisioning time in response to variations in available network resources. In particular, state migration permits to build path segments depending on the QoS requirements and resource availability emerged in previously established sub-paths.
For a detailed description of active path determination in ubiQoS, follow this link....

For experimental results and performance evaluations of the ubiQoS middleware follow the link...