We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Quality of Experience (QoE) API Specification (PRELIMINARY) - FIWARE Forge Wiki

Quality of Experience (QoE) API Specification (PRELIMINARY)

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Introduction to the QoE API

This section covers all the APIs related to the Quality of Experience. Please check the following Legal Notice to understand the rights to use these specifications.

This document describes the set of APIs for controlling and monitoring the QoE delivered to the network flows of an application. Such API enables widget developers to interact with a QoE manager (namely the QoE-Engine) to explicitly influence the allocation of network resources. The QoE engine is able to combine explicit QoE feedbacks coming from the user, with the QoS level provided by the network and other context related information. Such inputs are matched against a target QoE level to be achieved, and network resources are adaptively requested in order to approximate the target as much as possible. The QoE-Engine is able to request the allocation of network resources by interacting with a Mobility Manager (MM). The MM behaves as a proxy between the QoE-Engine and the Evolved Packet Core (EPC) that is directly responsible of the wise allocation of network resources. The API allows the developer to bind an application to the QoE framework, and track the evolution in time of the user's satisfaction and network's behaviour. It is also possible to control (run, pause or stop) the QoE monitoring, depending on whether the QoE of the user needs or not to be tracked.

Intended Audience

This specification is intended both for software developers, that are easily enabled to control user's QoE, by influencing the behaviour of very low level network bound processes, and also for API implementers.The QoE API is described in WebIDL then it is assumed that the reader is familiar with the WebIDL description language. Note that QoE APIs are not part of the W3C recommendation, but they represent a completely new set of APIs.

API change History

Revision Date Changes Summary
Mar 1, 2012 Initial version (Andrea Simeoni - Uniroma1 - asimeoni@dis.uniroma1.it)
  • Flow binding (start QoE monitoring)
  • Pause/Run the QoE monitoring.
  • Unregister the flow bind (stop the QoE monitoring)
Apr 23, 2012 2nd Draft (Andrea Simeoni - Uniroma1 - asimeoni@dis.uniroma1.it)
  • WebIDL API description
  • Ability to subscribe/unsubscribe for user's Click-Rate (active QoE) tracking.
  • Ability to subscribe/unsubscribe for delivered QoS (passive QoE) tracking.
  • Flow binding limited to URLs (needs extension to URIs).
Aug 27, 2012 3rd Draft (Andrea Simeoni - Uniroma1 - asimeoni@dis.uniroma1.it)
  • Support for Mean Opinion Score (MOS)
Mar 13, 2013 1st Working Version (Andrea Simeoni - Uniroma1 - asimeoni@dis.uniroma1.it)
  • getContext functionality
  • Refinement of the protocol between web application and QoE Engine, by defining the Message object

How to read this document

Use this document as a guideline to understand and use the provided API, via the WebIDL specification. API implementers can understand mechanisms running behind the QoE interface by reading the delailed description that completes the WebIDL.

Additional resources

The present open specification is strongly based on the WebIDL language. The WebIDL guide can be found at [1]. Architectural information on the QoE functional block can be found in the GE architecture deliverable.

General QoE API information

The QoE API provides a useful way for application developers to track and control the QoE evolution of the users connected to Future Internet services. This is done by providing a uniform JavaScript API on top, and a QoE engine process running at native level, which exposes the API. The QoE API doesn't need to access any kind of sensitive or protected information. Therefore its use is not tied to any kind of authorization or special permission. The API is strongly based on asynchronous operations, and is based on the natural JavaScript callback mechanism.


Design and Implementation

This section addresses key design and implementation concepts behind the QoE functionality in CDI. This section is useful both for QoE API users and developers. According to the FMC notation adopted in FI-WARE, the QoE system embedded on top of a CDI enabled device is described by the following picture.

Figure 1: CDI QoE system architecture


The following subsections give a description of all functional blocks depicted in the diagram.

APIHandler

Starting from the top of the picture the APIHandler can be found. Whenever a web applications developer wishes to take control of the user's QoE, he must interface with the APIHandler (client side) functional block. The API provided to the developer is the same described in the WebIDL in following sections, and can be imported with a double JavaScript import statement. The cdi.js specifies and loads the CDI frontend, while the webinos.js is just a dependency for the QoE API (note that not all the CDI APIs require webinos.js to work).


 <html>
  <body>
     ...
     <script type='text/javascript' src='webinos.js'></script>
     <script type='text/javascript' src='cdi.js'></script>
     ...
  </body>
 </html>

The client side APIHandler lives in the Web Runtime (WebRT), as well as the web application, and communicates asynchronously with the server side APIHandler. Such communication channel is bidirectional; and in the top-down direction it transports QoE API calls to be delivered at native level; in the bottom-up direction it transports return callbacks asynchronously originated at native level, in response to QoE API calls. FI-WARE CDI does not implement its own messaging channel and protocol, but exploits APIs provided by the hosting platform (PhoneGap, Webinos, Tizen). Whenever a call is generated by the application, it is packed and sent over the channel using the JavaScript messaging API provided by the hosting platform (i.e., API calls in webinos are formatted into JSON-RPC messages. There is a RPCHandler module showing up an API to pack and send JSON-RPC messages to the server side, and receive response callbacks. The messaging API is based on the HTML5 WebSockets API).

The server side APIHandler exploits the API provided by the Native Device Access to relay JavaScript calls to the Java layer (i.e., in webinos the server side APIHandler exploits the Java-Bridge component provided by webinos). Given its twofold nature, the server side APIHandler is half written in JavaScript and half written in Java. The JavaScript portion is in charge of mapping JavaScript calls to Java calls, using the API provided by the Native Device Access. The Java portion of the APIHandler forwards native Java calls to the QoE-Feedback component, using a callback based API (obviously asynchronous). Such callback based API has the very same signature of the JavaScript API described in the WebIDL below, and then also the same semantic. It is worth noting that the Java side of the APIHandler is in charge of starting up the whole QoE-Engine subsystem when the CDI framework is started. This fact is also highlighted in the FMC picture by means of a rounded corners rectangle containing the QoE-Engine process.

QoEFeedback

This functional block is in charge of interfacing with the application front end, to gather the end user expression of Quality of Experience. All QoE API calls pass through the QoEFeedback, that is also in charge to update the application Context database. Each interaction of the user with the QoE framework is captured by the QoEFeedback and registered into the Context. Communication with the application level is done through the Native Device Access API. The main role of the QoEFeedback is to explicitly handle user feedback (clicks) to compute a click rate value that represents the user's dissatisfaction. To perform this task it has to maintain a strong schedule for each monitored application's flow (one click rate for each flow). Once a computation of the user's click rate is available (i.e., each 10 seconds), this value is stored into the Context storage, so that it can be shared with other components running in the QoE-Engine. This functional block does not just provide feedback processing functionality, but also receives Mean Opinion Score (MOS) ratings by the application, in accordance with the corresponding WebIDL. Thus the interface exposed to the Native Device Access is a subset of the interface described in the WebIDL below, is completely asynchronous, and supports the giveFeedback and giveFinalScore functionalities.

Context

This functional block stores in main memory information about the context, making it available to all QoE Engine components. Such information includes:

  • Monitored flows.
  • Click rates for each monitored flow.
  • Monitoring status for each monitored flow (PAUSED, RUNNING).
  • Allocated QoS for each monitored flow.
  • Mean Opinion Score (MOS) value for each flow rated in the past

This component is thought to be further enriched with other context information (residual battery, memory and CPU usage, screen size etc.), that could be useful for the QoE-Controller to assess user's target QoE deviation in a more sophisticated way. Such extended context information is not difficult to be retrieved, since it can be directly provided by the CDI running system. Given the shared nature of the Context, exclusive access must be guaranteed to its records by means of a Context Manager (CtxtManager). Its role is to mediate the (read/write) access to the Context. CtxtManager offers an asynchronous interface to communicate with the server side APIHandler. This interface handles the commands of the JavaScript interface that don't bear user's feedbacks. That means all commands except giveFeedback and giveFinalScore. CtxtManager exposes a synchronous request-response interface to read/write the status of the Context. This interface is Java based and triggers notifications to the QoeFeedback whenever the Context is modified. The interface is obviously asynchronous, and is realized in Java by defining a CtxtEventListener interface. Up to now the only implementer of such interface is the QoeFeedback Java class, but ideally every implementer of the CtxtEventListener interface can be notified of context modification events. Events handled by a CtxtEventListener are: bind, unbind, pause, run.

QoSEngine

Cyclically for each monitored flow (extracted from the Context) this block communicates with the Mobility Manager to get the current QoS parameters status for that flow. Such communication should return bandwidth, packet-loss, jitter and delay information, but current implementations of the Mobility Manager only provide the bandwidth parameter. On the basis of such data, it updates the relative flow's context entry. The interface between the QoSEngine and the Mobility Manager is synchronous and monodirectional (request-response channel).

It supports the following functionalities:

  • REQUEST<FLOW_ID;PARAM> given a specific FLOW_ID associated to a monitored application's flow, the current value of PARAM is requested; RESPONSE<VALUE> provides the requested current value of PARAM. The only PARAM value supported by the Mobility Manager is the "bandwidth".

QoEController

This component assesses for each monitored flow (info coming from Context) if the provided QoE is compliant with an expected target value. For each monitored flow, it cyclically extracts Context's records, and combines them to assess the perceived user's QoE. If the provided QoE is not compliant with the expected QoE target level, a request is submitted to the Mobility Manager to leverage network resources for the considered flow. The interface that connects the controller to the Mobility Manager is asynchronous-monodirectional.

The following functionality is supported:

  • CHANGE<FLOW_ID;PARAM;RULE;VALUE> given a specific FLOW_ID associated to a monitored application's flow, its QoS PARAM (e.g. bandwidth, delay, jitter, packet loss, etc.) should satisfy the RULE (e.g. to be at MAX, to be at MIN, or to follow a REFERENCE) that is configured by a VALUE. As an example, CHANGE<FLOW_ID,BANDWIDTH,MIN,1000> can be interpreted as the FLOW_ID should have guaranteed a minimum bandwidth of 1000 Kbit/sec. Current implementations of the Mobility Manager only supports the bandwidth parameter.

Both QoSEngine and QoEController components are under development. They will be available in the next release.

Faults

Any faults encountered when invoking the QoE API will result in an error function being invoked. As already stated the interface is completely asynchronous, that is reflected also in the generation of faults. The callback that results from the generation of a fault, will contain an error object that brings a well detailed payload. The reader will find more details about errors in the WebIDL specification.

API operations

The QoE API is accessible under the window.fiware.cdi.qoe namespace. Alternatively it can be accessed through the shorter alias $cdi.qoe. The QoE interface supplies functions for:

  • Bind a flow to the QoE monitoring system
    The binding happens by passing a flow URL to the QoeApiHandler. When a flow is bound to the QoE framework, it can be monitored, and QoE feedbacks can be sent by the user that is currently consuming the flow.
  • Unbind a flow from the QoE monitoring system
    A monitored flow can be unregistered. The effect of such a call is that the QoE of the connection going on the flow's URL cease to be monitored.
  • Give bad QoE feedbacks to the underlying system
    The developer can attach this functionality to a button, or every graphical object the user can click. When a feedback is given, the underlying system assumes that the user is not happy of the current application session.
  • Pause/Run the monitoring process
    This functionality is accessed to handle situations in which the user is not paying attention to the flow (window in background, pause button pressed in a media player etc.).
  • Get context related information about a flow
    The developer can access information about the real time evolution of context parameters for a given flow. Such parameters include QoS measures (allocated bandwidth etc.), QoE measures (the user's current Click Rate) and other useful management info (flow monitoring status, flow registration status etc.).
  • Support for Mean Opinion Score (MOS) rating
    The developer can use this functionality to ask a user to express a summary rating on his QoE. The rating will be communicated to the underlying QoE system that will store such information to enrich the Context view. Context is further exploited as a knowledge base for future QoE assessment and manipulation. Five values can be chosen by the user: Excellent, Good, Fair, Poor, Bad.

The QoE API

After discovery and binding processes the API can be used by the application. The following WebIDL reports the API specification.

[NoInterfaceObject] interface QoeService{
    void bindFlow(in DOMString flowURL, in SuccessCB scb, in ErrorCB ecb);
    void unbindFlow(in int flowID ,in SuccessCB scb, in ErrorCB ecb);
    void giveFeedback(in int flowID, in SuccessCB scb, in ErrorCB ecb);
    void giveFinalScore (in int flowID, in int score, in SuccessCB scb, in ErrorCB ecb);
    void pauseQoeMonitor(in int flowID, in SuccessCB scb, in ErrorCB ecb);
    void runQoeMonitor(in int flowID, in SuccessCB scb, in ErrorCB ecb);
    void getContext(in int flowID, in SuccessCB scb, in ErrorCB ecb);
};

Callbacks

QoeService interface callbacks comply with the following structures.

callback SuccessCB = void(in Message msg);
callback ErrorCB = void(in Message errmsg);

Message objects

Every callback returned by the QoE framework brings a Message object. Message objects are javascript dictionaries organized as follows.

[NoInterfaceObject] interface Message{
     readonly attribute int flowID;
     readonly attribute CtxtDump ctxtdump;
     readonly attribute BadCallError bcerr;
};

In case of success callbacks relative to bindFlow, unbindFlow, pauseQoeMonitor, runQoeMonitor, giveFeedback and giveFinalScore calls, the only information conveyed to the developer is the flowID of the interested flow. That means bcerr and ctxtdump are set to undefined. Note that a valid flowID is a non zero positive integer. In case of getContext calls the ctxtdump field is a valid JavaScript dictionary with the following structure.

[NoInterfaceObject] interface CtxtDump{
    readonly attribute DOMString URL; //url associated to the flow
    readonly attribute Status status; // flow binding status
    readonly attribute MonitorStatus monitor; // flow monitor status 
    readonly attribute double AQS;    // Average QoS value in the range [0-1]. It is summarizes the network conditions faced by the flow
    readonly attribute double CR;     // User's measured click rate
    readonly attribute double D;      // Average delay of flow's packets
    readonly attribute double PLR;    // Packet loss rate for the flow
    readonly attribute double BW;     // Bandwidth allocated for the flow
    readonly attribute double MOS;    // MOS score expressed by the user
}
 
enum Status {"bound","not-bound"};
enum MonitorStatus {"running","paused","stopped"};

In case of returned error callbacks, the flowID field of the Message is set to zero, the ctxtdump is set to undefined, while the bcerr field is a valid JavaScript dictionary with the following structure.

[NoInterfaceObject] 
interface BadCallError{
   const unsigned short NO_EXISTING_SUBSCRIPTIONS=0;//still to be used
   const unsigned short INVALID_FLOW_ID=1;
   const unsigned short STATUS_INCOMPATIBLE_OP=2;
   const unsigned short BAD_URL=3;
   const unsigned short UNRECOGNIZED_METRIC=4; //still to be used 
   const unsigned short RATING_EXCEPTION=5;
   const unsigned short EXISTING_BIND=6;
   const unsigned short OTHER=7; 
 
   readonly attribute unsigned short code;
   readonly attribute DOMString message;
   readonly attribute DOMString code_desc; //literal version of the error code (i.e., 'EXISTING_BIND')
   readonly attribute BadArgument bad_arg; //details on the bad parameter that generated the error
  };
 
[NoInterfaceObject]
interface BadArgument{
    readonly attribute DOMString arg_name; //The name of the parameter generating the error
    readonly attribute DOMString arg_value; //The value of the parameter generating the error
}

bindFlow

void bindFlow (in DOMString flowURL, in SuccessCB scb, in ErrorCB ecb)
When invoked, it communicates to the underlying system that the user's QoE related to a certain network flow needs to be monitored.In case of success it asynchronously returns an integer a Message object containing an assigned flowID. bindFlow accepts three parameters:
  • DOMString flowURL : The network flow to be monitored is specified by means of a URI.
  • SuccessCB scb : Is asynchronously called in case of success. This callback brings the following information:
    • Message msg:
      • msg.flowID: It is the ID assigned by the QoE system to the network flow related to URL. This code identifies the flow in the system, and is always used to refer the flow when interacting with the QoE framework.
      • msg.bcerr: undefined
      • msg.ctxtdump: undefined
  • ErrorCB ecb: Is asynchronously called in case of error. This callback brings the following information:
    • Msg errmsg:
      • msg.flowID:0
      • msg.bcerr: describes the error. err comes with a message field that accurately specifies the cause of the error, and brings the following codes:
        • BAD_URI: if an invalid URI is provided.
        • EXISTING_BIND: if the provided URI is already registered.
      • errmsg.ctxtdump:undefined

unbindFlow

 void unbindFlow (in int flowID ,in SuccessCB scb, in ErrorCB ecb)
When invoked, it communicates to the underlying system to deregister the network flow identified by a certain flowID. unbindFlow accepts the following parameters:
  • int flowID : The network flow to be deregistered is specified by means of the ID obtained during the flow registration.
  • SuccessCB scb: The function asynchronously called in case of success. This callback brings the following information.
    • Message msg
      • msg.flowID: the deregistered flowID.
      • msg.bcerr:undefined
      • msg.ctxtdump:undefined
  • ErrorCB ecb: The function asynchronously called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with a possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework. This may happen for two reasons: the flow has already been unregistered, or the flow was never registered.
      • errmsg.ctxtdump:undefined

giveFeedback

 void giveFeedback (in int flowID, in SuccessCB scb, in ErrorCB ecb)
When called, it communicates to the underlying system that the user is not perceiving an adequate level of QoE for the flow identified by flowID. User feedbacks are elaborated by the QoE engine in the form of a Click-Rate, computed over a predefined time window (i.e., 10 sec). This method accepts three parameters:
  • int flowID : The network flow that the user is feeding back.
  • SuccessCB scb: The function asynchronously called in case of success. This callback brings the following information.
    • Message msg
      • msg.flowID: is the ID of the fed back flow.
      • msg.bcerr:undefined
      • msg.ctxtdump:undefined
  • ErrorCB ecb: The function asynchronously called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with a possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework.
        • STATUS_INCOMPATIBLE_OP: if the QoE monitoring of the flow is pause
      • errmsg.ctxtdump:undefined

giveFinalScore

 void giveFinalScore (in int flowID, in int score, in SuccessCB scb, in ErrorCB ecb)
When called, it returns a Mean Opinion Score rating to the underlying system. Such rating is usually communicated at the end of the user's experience. The QoE system will keep track of the MOS rating in the application Context DB. Such information can be exploited to perform better QoE assessments.giveFinalScore accepts the following parameters:
  • int flowID: the network flow that the user is rating.
  • int score: is the rating provided by the user, and must be an integer value between [1-5].
  • SuccessCB scb:: it is asynchronously called in case of success. This callback brings the following information:
    • Message msg
      • msg.flowID: is the ID of the rated flow.
      • msg.bcerr:undefined
      • msg.ctxtdump:undefined
  • ErrorCB ecb: Is called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with a possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework. This may happen for two reasons: the flow has already been unregistered, or the flow was never registered.
        • RATING_EXCEPTION: if an out of bound score is provided. Bounds are [1-5]
      • errmsg.ctxtdump:undefined

pauseQoeMonitor

 void pauseQoeMonitor (in int flowID, in SuccessCB scb, in ErrorCB ecb)
When invoked, the QoE monitor related to the specified flow is paused. This method can be called to manage moments in which the user is not paying attention to the flow (i.e., application is in background). This method accepts three parameters:
  • int flowID : The network flow whose monitoring must be paused.
  • StatusSuccessCB scb: Is asynchronously called in case of success. This callback brings the following information:
    • Message msg
      • msg.flowID: is the ID of the flow whose monitoring has been paused.
      • msg.bcerr:undefined
      • msg.ctxtdump:undefined
  • ErrorCB ecb: The function asynchronously called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework.
        • STATUS_INCOMPATIBLE_OP: if the QoE monitoring of the flow is already paused
      • errmsg.ctxtdump:undefined

runQoeMonitor

void runQoeMonitor (in int flowID, in StatusSuccessCB scb, in ErrorCB ecb)
When called, the QoE monitor is started, or theflowID that was previously paused is resumed. This method can be invoked to manage moments in which the user starts again paying attention to the flow (i.e., application passes in foreground). This method accepts three parameters:
  • int flowID : The network flow whose monitoring must be started or resumed.
  • StatusSuccessCB scb: Is asynchronously called in case of success. This callback brings the following information:
    • Message msg
      • msg.flowID: is the ID of the flow whose monitoring has been started or resumed.
      • msg.bcerr:undefined
      • msg.ctxtdump:undefined
  • ErrorCB ecb: The function asynchronously called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework.
        • STATUS_INCOMPATIBLE_OP: if the QoE monitoring of the flow is already running
      • errmsg.ctxtdump:undefined

getContext

 void getContext (in int flowID, in SuccessCB scb, in ErrorCB ecb)
When called, the QoE monitor returns to the application a snapshot of the overall flow context. This method accepts three parameters:
  • int flowID : The network flow whose context must be read.
  • StatusSuccessCB scb: Is asynchronously called in case of success. This callback brings the following information:
    • Message msg
      • msg.flowID: is the ID of the flow of interest.
      • msg.bcerr:undefined
      • msg.ctxtdump:is a valid CtxtDump object, populated as described in the WebIDL definition of the CtxtDump interface
  • ErrorCB ecb: The function asynchronously called in case of error. This callback brings the following information:
    • Message errmsg
      • errmsg.flowID: 0
      • errmsg.bcerr:is a valid BadCallError object with possible error codes:
        • INVALID_FLOW_ID: if the ID provided is not handled by the QoE framework.
      • errmsg.ctxtdump:undefined

API Usage Example

This section is meant to provide a representative example about the usage of the QoE interface.

window.addEventListener("onCDIReady",function(){
    var onSuccess = function(msg){
                        console.log("Flow ID: "+msg.flowID);
                        console.log("Context Dump info: "+msg.ctxtdump); // This field is 'undefined' for every call but getContext()
                        if(msg.ctxtdump != undefined){
                            console.log("Flow status: "+ msg.status);
                            console.log("Flow monitoring status: "+ msg.monitor);
                            console.log("Flow Average QoS: "+ msg.AQS);
                            console.log("Flow Click Rate: "+ msg.CR);
                            console.log("Flow Average Delay: "+ msg.D);
                            console.log("Flow Packet Loss Rate: "+ msg.PLR);
                            console.log("Flow allocated Bandwidth: "+ msg.BW);
                            console.log("Flow MOS score: "+ msg.MOS);
                        }
                        console.log("BadCallError: "+msg.bcerr);        //This field is supposed to be 'undefined' in a success callback
     }
 
 
    var onError   = function(errmsg){
                        console.log("Flow ID: "+errmsg.flowID); // In an error callback this field is supposed to be 'undefined'
                        console.log("Context Dump info: "+errmsg.ctxtdump); // Again this field shoud be undefined
                        console.log("Error code: "+errmsg.bcerr.code);
                        console.log("Error code description: "+errmsg.bcerr.code_desc);
                        console.log("Error message: "+errmsg.bcerr.message);
                        if(errmsg.bcerr.bad_arg != undefined){ //Is possible that an error is generated by a wrong parameter, in such
                                                               // case it is specified in the error
                            console.log("Bad arg name: "+errmsg.bcerr.bad_arg.arg_name);
                            console.log("Bad arg value: "+errmsg.bcerr.bad_arg.arg_value);
                        } 
    }
 
    var onFoundCb = function(service){
                     console.log("Found QoE service: ");
                     console.log("    Service Description: "+ service.description);
                     console.log("    Service API "+ service.api); // A URL that identifies the QoE API inside the Webinos framework
 
 
                         //Bind a flow to the underlying system
                         flowURL="http://cool-streaming-service/huge-stream.mp4";
                         $cdi.qoe.bindFlow(flowURL,
                         function(flowbindmsg){
                             //Run flow monitor (When you register a flow, you must run qOmonitoring in order to use the QoE interface)
                             $cdi.qoe.runQoeMonitor(flowbindmsg.flowID,onSuccess,onError);
                             //Give feedback
                             $cdi.qoe.giveFeedback(flowbindmsg.flowID,onSuccess,onError);
                             //Give MOS score
                             $cdi.qoe.giveFinalScore(flowbindmsg.flowID,5,onSuccess,onError);
                             //Pause flow monitor
                             $cdi.qoe.pauseQoeMonitor(flowbindmsg.flowID,onSuccess,onError);
                             //Context info retrieval
                             $cdi.qoe.getContext(flowbindmsg.flowID,onSuccess,onError); 
                             //Unregister the flow
                             $cdi.qoe.unbindFlow (flowbindmsg.flowID,onSuccess,onError);                            
                          }
                         ,onError)
                     }
    if($cdi.qoe.availability){
          onFoundCb($cdi.qoe.qoeServiceRef);
     }
});
Personal tools
Create a book