Main Page/Cloud Browser TF/UseCases/communication

introduction

Communication between the cloud browser and the RTE could be quite extensive. The image below depicts some of the possible information the RTE should communicate.

As shown in the image, communication between the client (RTE) and application (cloud browser) could be extensive due to all the state and services. The goal is to minimise this communication while adding enough functionality to allow for interoperability.

State

A fundamental feature is to communicate state. The best solution is to save all state in the cloud itself. However there are some circumstances where the client holds state as well. An example could be where middleware is installed on the client which handles system settings like captions, language, etc. This information should be exchanged with the application.

Services

The client could have different local services such as a tuner, decoder or a PVR as well as external services such as an attached screen or a conditional access module. In addition, the client could act as a hub for network services such as a smart device communicating with the app which needs to be started through DIAL or a paired Bluetooth headset which needs to be controlled through the application. Note that all services are dynamic. i.e. a external or network service could easily be turned off. It would be beneficial to get notified about such events. For example, consider the case where an application is able to start a PPV asset. Whether it is playable depends on the conditional access module. When an user removes the CA card, the application needs to be notified (because the asset shouldn't be playable anymore).

Capabilities and constraints

Each service has its own capabilities. For example, one TV could display HD1080p whereas another is only able to display HD720p. In addition, their video and audio decoders might only be able to decode certain formats. Those formats should be known by the application. In addition, the client could have constraints on the software. A typical example is the ability to handle the play-out. It could be that the player is only able to play-out unencrypted HLS for instance. Those capabilities should also be communicated.

Signalling

When a client communicates, it should provide sufficient information also known as signalling. In addition, it should signal the dynamic services, which, in this context, are all external and network services. If the state of a service changes, it should be pushed to the application and if the application need to change the state it will signal that to the client. The following section will provide some use cases divided into 6 main topics

• input
• output
• syncing
• hand-off functionality
• capabilities and constraints

Each topic has a use case overview together with some practical use cases.

input

title	UC: Client delegate input from service to application
brief	As an application i would like to receive service inputs so-that this input could be used to change the behaviour.
actors	actors client application service
main flow	a service receive input information the client receive the information from the service include::filter-input The client filters the information to decide if it needs to send the information to the application client delegate information application receive input information
extensions	2.1 an continuous stream from a media service is received 2.2 only essential information (such-as duration, current time, etc) is delegated to the application

user interaction

any interaction initiated by the user is part of the user interaction. usually an external service is used for input.

• a remote control sending key. the client receives the input and could decide to only forward a subset of all available keys to the application. The key mode could be different for example it could have a up or down or press state.
• a pointer device sending the pointer location to the application
• gesture commands (e.g. via a webcam) providing navigation direction (left/up/down/right/ok)
• user presses play button on a external dvd player
• user use an on screen or attached keyboard
• second screen device such as a smart phone, tablet.

sensors

sensors provide a high frequency of data

• ambient light information could be used to dim or brighting the user interface.
• cpu temperature is communicate to the application for diagnostic purposes

media

media data such-as a video stream from a camera is less practical to send from the client to the application. Therefore only relevant information should be send to control and obtain information from it.

• media duration is provided to the application
• audio play-time (position ) is provided to the application

output

Title	UC: application instruct output service
brief	As an application i would like to instruct output services so-that i am able to use them.
actors	client application service
main flow	an application instructs the client to use a output service the client receive the request include::service-state The client checks if the service is running the client delegate the request to the appropriate service service execute instruction

display

a display could be used to present the current UI or used to provide additional information . This UI could be fullscreen but it could also be partial. There could be theoretically multiple tv screens attached to one client. 

• the tv display changed resolution
• switch from source (e.g. SCART to HDMI
• on-screen-display progress bar on top of a video
• on-screen-display volume level information on top of a video
• led display of the client providing the current broadcast channel

sensory

• an pointer device could receive vibration if it is hovering on a focusable element. 
• provide specific colours to the ambient light to extend the UI experience

audio

• switch from stereo to dolby digital

hand-off functionality

Title	UC: application handoff functionality to the client
brief	As an application i would like to handoff functionality so that the client could delegate functionality to a service
actors	client application service
main flow	an application hands-off a functionality the client delegate the functionality to the service service execute functionality
extensions	2.1 an application instruct the client 2.2 lient delegate instruction to service

hand-off functionality

a client could have different native functionality. 

• play encrypted HLS on the native client
• open a native browser to surf the web

capabilities and constrains

Title	UC: application obtain client capabilities and constrains
brief	As an application i would like to retrieve client capabilities and constrained so that i could act on that
actors	client application
main flow	an application request client capabilities client provide capabilities and constrains

capabilities

the application could use different functionality based on the capabilities

• client device is able to switch from different resolutions (e.g. hd70p and hd1080i)
• able to hand-off HLS play-out

constrains

the application needs to know some of the constrains

• OSD is only able to display fixed set of colours

state

key/value state =

Basic state could be save in a key/value store and is usually sufficient.

• CAM card id needed to verify user by the application
• language setting specified by the native client software
• enable accessibility enhancements in video stream such as captions / subtitles, descriptions, sign language, etc
• client is parental controlled
• pin code for parental control
• channel is locked for parental control

blob

a blob could needed to provide more information than just a key/value store

• on screen display images updated from the application to the client
• firmware updates from the application to the client