Tizen and HTML5

The Tizen SDK is a comprehensive set of tools for developing Tizen web and native applications. Tizen is based on the Linux kernel and the GNU C Library implementing the Linux API. It targets a very wide range of devices including smartphones, tablets, in-vehicle infotainment (IVI) devices, smart TVs, PCs, smart cameras, wearable computing (such as Smartwatch), Blu-ray Players, Printers and Smart Home Appliances. Its purpose is to offer a consistent user experience across devices, allowing developers to use HTML5 and related Web technologies to write applications that run on supported devices.

In October 2014, the Worldwide Web Consortium elevated the HTML5 specification to ‘recommendation’ status , giving it the group’s highest level of endorsement, which is to becoming a standard. The W3C also introduced Application Foundations with the announcement of the HTML5 recommendation. Open Web Platform (OWP) is a set of technologies for developing distributed applications with the greatest interoperability among different terminal devices. HTML5 plays a key role to that.

In this framework, Tizen Association works closely with the Linux Foundation which runs the Tizen open source project (Tizen.org), with a focus on platform development and delivery.

Samsung, a member of Tizen association, has launched Tizen-based Samsung TVs and has released also the relative Tizen SDK and Caph SDK, in order to support the development of web applications and promote in the market device independent apps. Both SDKs are available for downloading at http://www.samsungdforum.com/

QoE-FI 2015

IEEE Workshop on Quality of Experience-Based Management for Future Internet Applications and Services

Recent technological advances have enabled a constant proliferation of novel immersive and interactive services that pose ever-increasing demands to our communication networks and add to their load. Examples are: social TV, immersive environments, mobile gaming, HDTV over mobile, 3D virtual world, book/newspaper consumption, social networking, IPTV applications, just to cite a few. Some of these services have already reached a major market success especially because a user-centered approach has been followed to design the whole process of content production, service activation, content consumption, and service (and network) management.
In addition, we witness the trend of migrating end-to-end multimedia communication systems/platforms to the cloud. Media processing and consumption in the cloud requires attention from two main perspectives: maintenance of processing-related cloud operations over the execution time considering the end-user and application-related QoS/QoE requirements via dynamic resource provisioning; and the parallelization and abstraction of media processing tasks for the optimization of limited and shared cloud resources. Furthermore, the domain of Smart Cities offers new opportunities and use cases, but at the same time poses new challenges for keeping users engaged and interested in those services. This also includes other aspects such as quality of life as well as critical considerations such as user safety, particularly when it comes to urban transport and emergency scenarios.
In this dynamically evolving context, network operators and service providers are struggling to keep their increasingly sophisticated customers content while remaining profitable at the same time. Consequently, optimization and management of QoE has become crucial issue in the deployment of successful services and products. However, even if the concept itself may seem straightforward to understand, it requires rather complex implementation processes for efficient performances in real end-to-end systems/networks. The complexity of QoE is mainly due to the difficulties in its modelling, evaluation, and mapping to objective Quality of Service (QoS) parameters, which,for more than a decade, has been used as a partial substitution to QoE, and due to its multi-dimensional end-to-end nature covering a wide range of networks, applications, systems, devices, contexts and expertise.

On this background, the workshop is aimed at bringing together researchers from academia and industry to identify and discuss technical challenges, exchange novel ideas, explore enabling technologies, and report latest research efforts that cover a variety of topics including, but not limited to:

- QoE evaluation methodologies and metrics
– Frameworks and testbeds for QoE evaluation (crowd-sourcing, field testing, etc.)
– QoE studies & trials in the context of Smart Cities
– QoE models, their applications and use cases
– QoE for immersive audio-video and interactive multimedia communication environments
– QoE-aware cross-layer design
– QoE-driven media processing and transmission over the cloud and over the top (OTT)
– QoE control, monitoring and management strategies
– QoE in community-focused interactive systems
– KPI and KQI definition for QoE optimization in different environments
– Integration of QoE in infrastructure and service quality monitoring solutions
– Media analytics from QoE Big Data
– Standards for media coding (HEVC, HEVC for 3D, etc.) and transport (DASH, MMT, XMPP, etc.)
– Future Media Internet architectures

Submitted papers must represent original material which is not currently under review in any other conference or journal and has not been previously published. Paper length should not exceed the six-page standard IEEE conference two-column format. Please see the author information page for submission guidelines on the ICC 2015 website http://icc2015.ieee-icc.org

Link: http://qoe-fi.diee.unica.it
When Jun 8, 2015 – Jun 12, 2015
Where London
Submission Deadline Jan 10, 2015
Notification Due Feb 14, 2015
Final Version Due Feb 15, 2015

 

System Requirements Wording

Usually I receive from my students (especially during thesis supervision) the question if there is a standard way to describe the wording of a system requirements.
An interesting approach to this is IETF RFC 2119, which defines the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”

1. MUST This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

For more info please refer to the RFC here