ETSI TS 103 320 V1.1.2 (2015-05)

Digital Video Broadcasting (DVB); GEM Companion Screen Service Framework

RTS/JTC-DVB-361

General Information

• Status: Published
• Publication Date: 26-May-2015
• Technical Committee: BROADCAS - EBU/CENELEC/ETSI on Broadcasting
• Current Stage: 12 - Completion
• Due Date: 27-May-2015
• Completion Date: 27-May-2015

Standards Content (Sample)

TECHNICAL SPECIFICATION
Digital Video Broadcasting (DVB);
GEM Companion Screen Service Framework

�
2 ETSI TS 103 320 V1.1.2 (2015-05)

Reference
RTS/JTC-DVB-361
Keywords
companion screen, GEM, UPnP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
© European Broadcasting Union 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 320 V1.1.2 (2015-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 10
4 Companion Screen Service Framework . 10
4.1 Introduction . 10
4.1.0 Overview . 10
4.1.1 Core Framework Functions . 11
4.1.2 Application-Defined Functions . 11
4.2 Framework Architecture . 12
5 GEM Companion Service Model . 13
5.1 GEM Companion Service . 13
5.1.0 Overview . 13
5.1.1 Service Types . 14
5.1.2 Publishing Services . 14
5.1.3 Protocol Endpoints . 14
5.1.4 Resources and State variables . 14
5.1.5 Notifications . 14
5.1.6 Naming of Companion Service . 15
5.2 Service Manager . 15
5.2.0 Overview . 15
5.2.1 Service lifecycle . 16
5.2.2 Private Mode . 16
5.3 Service deployment . 17
6 Discovery and Association . 17
6.0 Overview . 17
6.1 Service use without discovery (Phase 1) . 17
6.2 Service Discovery on the local network (Phase 1+) . 17
6.2.0 Dynamic service discovery . 17
6.2.1 Introduction (informative) . 18
6.2.1.0 Outline . 18
6.2.1.1 UPnP Device Architecture . 18
6.2.1.2 UPnP Application Management . 19
6.2.1.3 GEM companion service mapping on Application Management. 20
6.2.1.4 CSA behaviour . 21
6.2.2 UPnP Device requirements for the GEM Device . 24
7 External Service Interface . 25
7.0 Services . 25
7.1 REST Companion Service . 25
7.1.0 Overview . 25
7.1.1 Notifications . 25
7.1.2 JSON Data Format . 25
7.1.3 REST Companion Service API . 26
7.2 Web sockets . 26
7.3 Core Services . 27
ETSI
4 ETSI TS 103 320 V1.1.2 (2015-05)
7.3.1 Device State Service . 27
7.3.1.0 Overview . 27
7.3.1.1 APIs for DeviceStateService . 27
7.3.2 Companion Synchronization Service (CSS) . 28
8 Framework API . 29
9 API Sequence Diagrams (informative) . 30
9.0 Overview . 30
9.1 REST service provided by an application . 31
9.2 CSS CII Service . 33
9.3 Service with subscription . 34
Annex A (informative): Bibliography . 35
History . 36

ETSI
5 ETSI TS 103 320 V1.1.2 (2015-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European
Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European
Telecommunications Standards Institute (ETSI).
NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body
by including in the Memorandum of Understanding also CENELEC, which is responsible for the
standardization of radio and television receivers. The EBU is a professional association of broadcasting
organizations whose work includes the co-ordination of its members' activities in the technical, legal,
programme-making and programme-exchange domains. The EBU has active members in about
60 countries in the European broadcasting area; its headquarters is in Geneva.
European Broadcasting Union
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: [phone]
Fax: [phone]
The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network
operators, software developers, regulatory bodies, content owners and others committed to designing global standards
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data.
The consortium came together in 1993 to provide global standardization, interoperability and future proof
specifications.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Enhanced TV DVB-services, based on the "Digital Convergence" paradigm, are becoming available today in a variety
of forms in the digital marketplace. The market has seen an explosion in the distribution and consumption of audio and
video content through a variety of connected devices, like smart phones, tablets, PCs, and hybrid STBs and TVs
(typically connected to the broadcast and to the broadband channels).
It is recognized that a new, emerging trend is expanding the focus of interactive services from the main TV screen only
to a wide range of different connected companion screens, extending the range of possibilities and providing new levels
of engagement to end users.
ETSI
6 ETSI TS 103 320 V1.1.2 (2015-05)
The commercial success of personal and portable devices, often used as a second or companion screen by the user to
search and retrieve information or additional content while watching traditional TV services, creates new opportunities
to provide compelling services based on interactions among users, devices and content.
For the DVB GEM Middleware (specified in ETSI TS 102 728 [1]), a deeper investigation of the evolution of
interactive TV services has happened, envisaging how those services will integrate companion devices to meet user's
expectations in the near future.
Based on clear use cases to support interactions with the main TV screen and related content consumption also from
companion screens, a set of GEM extensions has been defined which are described by the present document.
These extensions are called the GEM Companion Screen Service Framework.
The GEM Companion Screen Service Framework includes a service capable of delivering synchronization information
as defined by ETSI TS 103 286-2 [2]: "Digital Video Broadcasting (DVB); Companion Screens and Streams; Part 2:
Content Identification and Media Synchronization".
ETSI
7 ETSI TS 103 320 V1.1.2 (2015-05)
1 Scope
The present document specifies the GEM Companion Screen Service Framework, which is addressing the Phase 1 and
1+ of DVB's companion screen requirements. These requirements ask for extensions of the GEM middleware
specification ETSI TS 102 728 [1], to support information exchange and synchronization between the companion
screen and the primary service.
The Companion Screen Service Framework provides the infrastructure for GEM companion services that offer their
functionality to companion devices in the home network. GEM companion services allow broadcasters and content
providers to dynamically provide companion services that integrate screen devices, such as mobile phones, tablets, PCs
etc. into the viewing experience.
GEM companion services can be deployed via regular GEM applications and enable the broadcaster and content
provider to dynamically add companion services, thus augmenting the experience of the viewer to companion devices.
These companion devices can communicate with the GEM companion services via standardized protocols (e.g. UPnP,
REST, WebSockets) or can chose to implement proprietary communication protocols.
The framework defines a common discovery mechanism based on the UPnP Application Management Service for these
services.
The companion screen service framework as defined by the present document is orthogonal to GEM profiles and
versions and can be used on all GEM platforms and derived platforms (MHP, OCAP, BD-J).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 728: "Digital Video Broadcasting (DVB); Globally Executable MHP (GEM)
Specification 1.3 (including OTT and hybrid broadcast/broadband)".
NOTE: Available at
http://www.etsi.org/deliver/etsi_ts/102700_102799/102728/01.02.01_60/ts_102728v010201p.pdf.
[2] ETSI TS 103 286-2: "Digital Video Broadcasting (DVB); Companion Screens and Streams;
Part 2: Content Identification and Media Synchronization".
NOTE: Available at
http://www.etsi.org/deliver/etsi_ts/103200_103299\10328602/01.01.01_60/ts_10328602v010101p.pdf.
[3] ISO/IEC 29341 (September 2014): "UPnP ApplicationManagement:1 Service".
NOTE: Available at http://upnp.org/specs/ms/UPnP-ms-ApplicationManagement-v1-Service.pdf.
[4] IETF RFC 2616 (1999): "Hypertext Transfer Protocol -- HTTP/1.1".
NOTE: Available at http://www.ietf.org/rfc/rfc2616.txt.
[5] IETF RFC 6455 (December 2011): "The WebSocket Protocol".
NOTE: Available at http://tools.ietf.org/html/rfc6455.
ETSI
8 ETSI TS 103 320 V1.1.2 (2015-05)
[6] ETSI EN 300 468 (V1.14.1): "Digital Video Broadcasting (DVB); Specification for Service
Information (SI) in DVB systems".
NOTE: Available at
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.14.01_60/en_300468v011401p.pdf.
[7] ETSI TS 102 809: "Digital Video Broadcasting (DVB); Signalling and carriage of interactive
applications and services in Hybrid broadcast/broadband environments".
NOTE: Available at
http://www.etsi.org/deliver/etsi_ts/102800_102899/102809/01.02.01_60/ts_102809v010201p.pdf.
[8] ISO/IEC 29341-1:2011: "Information technology -- UPnP Device Architecture -- Part 1: UPnP
Device Architecture Version 1.0".
NOTE: Available at http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf.
[9] IETF RFC 2818 (2000): "HTTP Over TLS".
NOTE: Available at http://tools.ietf.org/html/rfc2818.
[10] IETF RFC 7159 (2014): "The JavaScript Object Notation (JSON) Data Interchange Format".
NOTE: Available at http://tools.ietf.org/html/rfc7159.
[11] Java API for JSON (JSON in Java).
NOTE: Available at http://www.json.org/java/index.html.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] "Principled Design of the Modern Web Architecture", ROY T. FIELDING and RICHARD N.
TAYLOR, May 2002.
NOTE: Available at http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf.
[i.2] ETSI TR 103 286-1: "Digital Video Broadcasting (DVB); Companion Screens and Streams;
Part 1: Architecture".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
application: functional implementation realized as software running in one or spread over several interplaying
hardware entities
association: process or act of establishing a link between a primary TV device and a companion screen application
NOTE: The link does not need to be exclusive or permanent.
ETSI
9 ETSI TS 103 320 V1.1.2 (2015-05)
companion screen: personal and usually portable device such as a smart phone, a tablet PC or a laptop with broadband
connectivity
NOTE: It is sometimes referred also as "second screen".
companion screen application: software application that executes on a companion screen and enhances the main TV
screen experience
companion screen event: event sent to companion screen application related to a change in primary device state
companion screen service framework: extension of GEM that is integrated in the GEM platform to expose primary
screen functions to companion screens
NOTE: The companion screen framework is specified by the present document.
companion service: feature provided by the primary device to the companion devices
GEM application: application running upon a GEM middleware
GEM device: device running GEM middleware
GEM companion service: companion service offered by a GEM device
GEM middleware: middleware which agrees to GEM specification and requirements
GEM platform: GEM device
hybrid STBs: STB connectable to internet
home network: local network within the home
NOTE: Devices are connected via Wifi or Ethernet. A router/gateway device connects the home network to the
Internet via an ISP.
middleware: computer software that provides services to software applications beyond those available from the
operating system
notification: message from a primary device to a companion screen application that is sent upon the state changes in
the state of the primary device
primary device: TV or STB for receiving and decoding digital television services
NOTE: It may include (personal) video recorder functions, access to additional IP based on-demand services,
interactive applications, etc. It is a shared device that, in the context of the present document, could be
hierarchically referenced with a companion screen (i.e. a personal portable device).
primary device state: body of information which describes the state of the primary device at a particular time
NOTE: It is composed by information related to TV service (present & following) and information about primary
device settings.
primary GEM device: primary device running GEM middleware
primary screen: primary device
primary service: TV service played by the primary device
service: grouping (usually defined by a PMT) of one or more data streams which are offered as a whole to the user
subscription: mechanism for a companion screen application to register itself to primary device in order to receive
notifications
transient application: interactive application running upon primary device in agreement to GEM application lifecycle
NOTE: It can be provided both from broadcast and broadband feed.
ETSI
10 ETSI TS 103 320 V1.1.2 (2015-05)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AIT Application Information Table
AMS Application Management Service
API Application Programming Interface
BD-J Blu-ray Disc Java
CII Content Identification and Information
CSA Companion Screen Application
CSS Companion Screen Services
CSS-WC CSS-Wall Clock
DCP Device Control Protocol
DDD Device Description Document
DVB Digital Video Broadcasting
GEM Globally Executable MHP
GENA General Event Notification Architecture
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IETF Internet Engineering Task Force
IP Internet Protocol
JSON JavaScript Object Notation
MHP Multimedia Home Platform
MUG MHP Users Group
OCAP OpenCable Application Platform
PC Personal Computer
PMT Program Map Table
QR-code Quick Response Code
REST REpresentational State Transfer
RFC IETF Request for Comments
RPC Remote Procedure Call
SI Service Information
SOAP Simple Object Access Protocol
SSDP Simple Service Discovery Protocol
STB Set Top Box
TCP Transmission Control Protocol
TE Trigger Event
TS Timeline Synchronization
TV Television
UDA UPnP Device Architecture
UDN Unique Device Name
UDP User Datagram Protocol
UI User Interface
UPnP Universal Plug and Play
URI Uniform Resource Identifier
WC Wall Clock
XML eXtensible Markup Language
4 Companion Screen Service Framework
4.1 Introduction
4.1.0 Overview
The model of interaction between companion screen applications and a GEM device is based on the concept of the
Companion Screen Service Framework. This framework is included in the GEM middleware; it is able to expose
functions of the primary GEM device to companion screens directly or via a GEM application. Those functions,
conceptually equivalent to APIs, may be used to retrieve information about the status of the primary device or to control
its behaviour. The availability of these functions is not related or influenced by the GEM application lifecycle when
companion screens interact directly with functions provided by the Companion Screen Service Framework.
ETSI
11 ETSI TS 103 320 V1.1.2 (2015-05)
4.1.1 Core Framework Functions
The Companion Screen Service Framework provides a set of functions defined as core functions that can be accessed
directly by companion screen applications. This is a subset of all the possible functions exposed by the primary device.
In line with the GEM traditional model, specific sensitive controls or information (typically those more content-related)
can only be accessed through a GEM application, therefore with a direct control by the broadcaster.
Companion
CS APP
Screen Device
CS Framework APIs
GEM APIs
Primary
Device
CS
Framewor         k GEM

Figure 1: Core Framework Functions
4.1.2 Application-Defined Functions
A companion screen application can access a richer set of functions (including those provided by the Companion Screen
Service Framework) when a GEM application, designed to support it, is active on the primary device. This model of
interaction is directly under the control of the broadcaster.
In this case, as depicted in Figure 2, the GEM application can implement specific logic to handle the requests coming
from a companion screen application, and can then access Companion Screen Service Framework functions via local
GEM APIs. In this model, constraints imposed by the GEM application lifecycle apply.
Companion
CS APP
Screen Device
GEM APP
CS Framework APIs GEM APIs
CS
GEM
Framework
Figure 2: Application-Defined Functions
Through a GEM application, the broadcaster can implement companion screens functionalities with customized and
flexible authentication and authorization mechanisms (if required), and can access a variety of sensitive functions
exposed by the Companion Screen Service Framework (e.g.: interaction with the TV service on the main TV,
redirection of content, etc.).
ETSI
12 ETSI TS 103 320 V1.1.2 (2015-05)
4.2 Framework Architecture
The Companion Screen Service Framework offers the common infrastructure to provide its services (Companion
Services) to the companion screen applications as a set of services. The Companion Services defined by the present
document address the requirements for Phase 1 and Phase 1+. They can be extended by services defined in later phases
of the companion screen work.
The framework provides the necessary infrastructure to seamlessly integrate Companion Services, that are defined by
later specifications and also supports dynamically extending the set of available Companion Services via transient GEM
applications. Companion Services can be used by multiple companion devices simultaneously, where companion
devices may run multiple connected applications. Companion Services can provide multiple protocol endpoints for
using them via different protocols.
All Companion Services are handled by the Service Manager, which implements common functionalities for the
discovery and management of Companion Services.
transient application i [i={0 . I}] companion service k [k={0 . K}]
Service Manager
CS application d
Protocol g
[d={0 . D}]
companion service j [j={0 . J}]
end-point f
[g={0 . G}]
[f={0 . F}]
Companion Device u
Device State Service
[u={0 . U}]
Companion Synchronisation
Service
core services
CS Service Framework
GEM primary device
Figure 3: Framework architecture
In order to address use cases requested by the commercial requirements for Phase 1 and Phase 1+ the framework
defines a couple of core services, that are described in clauses 7.1 and 7.2 of the present document. Such services
expose to companion screen application information which can be grouped as follow:
• Device Status Information
Status Information is handled by the Device State Service, which enables a companion screen application to be
aware about:
- status of the content played upon the primary device, e.g. service name;
- status of the primary device, e.g. list of GEM applications.
ETSI
13 ETSI TS 103 320 V1.1.2 (2015-05)
• Content Synchronization Information
Synchronization Information is handled by the Companion Synchronization Service, which enables a
companion screen application to get information related to the timeline of content presented on the primary
device.
These services are Core Services, which are included in the platform; they provide synchronous and asynchronous
communication interfaces between primary device and companion screen applications.
5 GEM Companion Service Model
5.1 GEM Companion Service
5.1.0 Overview
A Companion Service is a software component that manages a set of state variables (resources). These state variables
can change over the lifetime of the service and represent a model of the functionality provided by the service.
State variables are strings. They have a type and a value that can be queried or changed via operations.
Execution of a command can be triggered via a method call on the external API. The external API can be called directly
from a Java application or is used by a protocol endpoint via a protocol handler. This exposes the external API to
Companion Screen Applications.
A Companion Service provides one or more protocol endpoint to offer an external interface to companion screen
applications via a specific protocol.
The Companion Service model supports dedicates service types that enable notifications on changes to the service state.
This allows registered subscribers to be notified of a change of the state of the service, i.e. a change to one or more of
the state variables.
Internal API
Companion Service
Protocol Endpoint
s
r
Command
e
l
d
(Actions)
n
a
h
l I
o
P
c
A
o
l
t
a
o
n
r
Protocol Endpoint
r
p Eventing
e
a t
i
x
v
E
g
n
i
p
p
a
Resources
M
Protocol Endpoint
(State Variables)
Figure 4: Companion Service Model
ETSI
14 ETSI TS 103 320 V1.1.2 (2015-05)
5.1.1 Service Types
The GEM companion screen service framework defines the following service types with appropriate protocol handlers:
• REST.
• WebSocket.
• CSS.
An application can use these service types and benefit from the underlying protocol support or it can implement
proprietary protocols by defining its own protocol endpoints and protocol handlers.
5.1.2 Publishing Services
A service is available to applications and services within the platform. To make it usable for external clients, it has to be
discoverable via a common discovery mechanism and it has to provide one or more protocol endpoints that are used for
communication with external clients.
The discovery mechanism is defined in clause 6.
The framework does not put obligations on the protocols that can be used on a protocol endpoint to communicate with
companion services but provides a common mechanism to integrate various protocols.
5.1.3 Protocol Endpoints
A protocol endpoint terminates an external network communication interface in the GEM platform. An external
protocol is mapped by the platform to API calls of the service interface via a protocol handler. Protocol handlers are
internal to the platform and provide a bridge between an external communication protocol (terminated with an IP
address and a port number) and a service interface. The GEM companion screen service framework provides protocol
support for REST over HTTP/HTTPS, the CSS protocols and WebSockets.
5.1.4 Resources and State variables
A Companion Service encapsulates a set of resources (state variables) and provides a set of commands to get or set the
resource values.
All Companion Service resources are of type String.
NOTE: A service may choose to encode structured information in the String by using JSON IETF RFC 7159 [10]
notation.
A Companion Service can provide information to the interested companion screen applications in an asynchronous way
about change in the state some of its resources. This mechanism is called notification and is described in clause 5.1.5.
5.1.5 Notifications
The notification mechanism allows companion screen applications to receive messages about companion service's
events (CS-event) in an asynchronous way. The primary device sends messages to companion device as soon as the
corresponding CS-event happens, without any explicit request.
Notifications are sent using WebSocket protocol IETF RFC 6455 [5].
When a Companion Service is starting it shall create and open a WebSocket server and include its connection address in
the AppToAppInfo section that is used during the discovery phase (see clause 6.2). There are no restrictions in a type of
connection, i.e. the connection can be secured (wss://) or unsecured (ws://).
When a value of an evented resource changes then a Companion Screen sends a corresponding message using
WebSocket channel. The payload format is defined in clause 7.1.1.
A companion screen application interested in events connects to a WebSocket address acquired during discovery phase
and listen for messages.
When the Companion Service is deregistered, WebSocket channel is closed and events are no longer available.
ETSI
15 ETSI TS 103 320 V1.1.2 (2015-05)
5.1.6 Naming of Companion Service
All Companion Services carry a unique name. Companion Services shall be named according to the definitions in
ISO/IEC 29341 [3] and clause 6.2 of the present document.
Names of a Companion Service and its matchingProtocolNames are given by the Companion Service creator.
As described by clause 6.2, the name of a Companion Service and its matchingProtocolName are used by the CSA to
obtain information about the services provided by the primary device.
The matchingProtocolName schema is defined by:
matchingProtocolName := ”.GEM.DVB.org_v1”

The names of platform-provided Companion Services are predefined by clauses 7.1 and 7.2 of the present document.
The names of application-provided Companion Services shall follow the same schema.
5.2 Service Manager
5.2.0 Overview
As introduced by Figure 3, companion screen applications are able to access services on the primary device through the
Service Manager. It is a software module, which is started at platform startup of the primary device and it remains
running while the primary device is on.
Some of the tasks of the Service Manager were already introduced, additional functions include:
1) Service Manager shall manage registration for available Companion Services provided by the GEM platform
(static).
2) Service Manager shall manage registration for available Companion Services provided by a GEM application
(transient).
3) Service Manager shall manage the state of the Companion Services (lifecycle).
4) Service Manager shall provide all information related to the list of started Companion Services to companion
screen applications.
5) Service Manager shall manage "private mode", see clause 5.2.2 in the present document.
6) Service Manager shall provide user information about Companion Services available on the primary device.
The Service Manager supports discovery as defined by ISO/IEC 29341 [3] which is described by clause 6.
Service Manager
Registered companion services
Static companion service 1
Static companion service Static companion service
……
Static companion service Static companion service
Transient companion service 1 Static companion service 1
……
Static companion service n
Transient companion service 1
……
Application-provided companion services platform-integrated companion services
……
Transient companion service m

Figure 5: Companion Service registration
There is no difference between the registration and possible functionality between a platform-integrated companion
service and application-provided companion service.
ETSI
16 ETSI TS 103 320 V1.1.2 (2015-05)
Application-provided companion services can add features to the platform. It is not possible that an application-
provided companion service replaces a platform-provided companion service.
Application-provided companion services and platform-integrated companion services can be used simultaneously by
the same or by multiple companion screen applications.
5.2.1 Service lifecycle
A GEM companion service follows a lifecycle: It is always in one of the following execution states.
Table 1: Service Lifecycle
State Description
Registered The service was registered with the service manager
Started The service is active and accepting requests from the external interface
Paused The service is on standby and not accepting requests from the external interface
Stopped The service is stopped and ready to be either started again or to be unregistered
Unregistered The service is not registered with the service manager

Service transitions are described in figure 6.

Figure 6: State model for Companion Service
State changes are caused by method calls on the Service Manager.
5.2.2 Private Mode
The Service Manager offers a way to set the Private Mode state, where all companion services are paused and do not
respond to requests from companion screen applications. All incoming requests during the Private Mode to the
Companion Services are ignored.
When the Private Mode is set, the Service Manager is able only to manage request from the user to exit from the Private
Mode.
Companion Screen services, that are registered and started during the Private Mode, are automatically paused. Event
notifications are not sent until leaving the Private Mode.
During the Private Mode, the Service Manager returns an empty list of started Companion Screen services.
Only the user can set/unset Private Mode by means of a dedicated UI provided by the GEM Primary Device; for this
purpose the Companion Screen Service Framework shall provide APIs.
ETSI
17 ETSI TS 103 320 V1.1.2 (2015-05)
Such APIs act upon all registered Companion Services, i.e. the user has no access to each single registered Companion
Service.
5.3 Service deployment
Platform-integrated Companion Services are registered during system initialization and are available during the entire
up time of the platform. Application-provided Companion Services are transient, i.e. they are only available while their
corresponding application is available, e.g. during the presentation of a TV service. They are registered by an
application during its initialization and shall be deregistered by the application before the application terminates.
Transient Companion Services are packaged and deployed in complete agreement to lifecycle of the application which
register them. For details refer to the application model for GEM which is defined in ETSI TS 102 728 [1], clause 9.
There is no specific signalling or dedicated application type for applications that provide Companion Services.
A service is started by the application and is available as long as the application is available. When an application that
provided a service is terminated, it shall stop and unregister all CS-services that were created by it.
NOTE: To protect the integrity of the companion screen service framework, a platform may clean up services that
were not properly stopped or terminated by the application after the creating application has terminated.
6 Discovery and Association
6.0 Overview
The present document supports two operation variants to enable a companion screen application consuming services on
the primary device.
The first mode assumes a preconfigured system, i.e. the linkage between a companion screen application and its
companion services happens without discovery. This mode is further described in clause 6.1 in the present document.
The second mode uses UPnP Application Management Service to dynamically discover and announce companion
services. This mode is further described in clause 6.2 in the present document.
It is out of scope of the preset document to define a
...