ETSI TS 103 426 V1.1.1 (2016-11)

Publicly Available Specification (PAS); Smart Machine-to-Machine communications (SmartM2M) Home Gateway Initiative RD048-HG Requirements For HGI Open Platform 2.1

DTS/SmartM2M-103426

General Information

• Status: Published
• Publication Date: 07-Nov-2016
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 14-Dec-2016
• Completion Date: 08-Nov-2016

Standards Content (Sample)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Smart Machine-to-Machine communications (SmartM2M)
Home Gateway Initiative
RD048-HG Requirements For HGI Open Platform 2.1

CAUTION
The present document has been submitted to ETSI as a PAS produced by HGI and
approved by the ETSI Technical Committee Smart Machine-to-Machine communications (SmartM2M).
HGI was owner of the copyright of the document (RD048) and/or had all relevant rights and had assigned said rights to ETSI on
an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties whether express, implied,
statutory or otherwise including but not limited to merchantability, non-infringement of any intellectual property rights of third
parties. No warranty is given about the accuracy and the completeness of the content of the present document.

2 ETSI TS 103 426 V1.1.1 (2016-11)

Reference
DTS/SMARTM2M-103426
Keywords
GATEWAY, Home Gateway, intelligent homes &
buildings
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
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 2016.
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 426 V1.1.1 (2016-11)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope and purpose of the present document . 7
1.1 Abstract . 7
1.2 Scope and purposes . 7
1.3 What is new compared to HGI-RD008 and to RD-048v1? . 7
1.3.1 RD-048v1 compared with RD-008 [i.20] . 7
1.3.2 RD-048v2 compared with RD-048v1 . 8
1.4 Relationship with HGI residential profile . 8
2 References . 9
2.1 Normative references . 9
2.2 Informative references . 9
3 Definitions and abbreviations . 11
3.1 Definitions . 11
3.2 Abbreviations . 11
4 Architecture . 11
4.1 Roles and entities . 11
4.2 Entities in the open platform 2.1 - enabled home gateway . 12
4.3 Home gateway software architecture . 13
4.3.1 Essentials . 13
4.3.2 Details . 13
4.4 Access to smart home non IP networks . 14
4.5 Remote management . 14
4.5.1 Essentials . 14
4.5.2 Details . 14
4.5.3 Issues with firmware updates and software module management . 15
5 Generic requirements . 15
5.1 Basic requirements . 15
5.2 Reliability and security . 16
5.3 Life cycle management . 16
5.3.1 General . 17
5.3.2 Installation . 17
5.3.3 Uninstallation . 17
5.3.4 Update . 17
5.3.5 Start . 17
5.3.6 Stop . 18
5.4 Remote management . 18
5.5 Module dependencies and interaction . 19
5.6 Supported protocols stacks . 19
5.7 HG application programming interface (HG_API) . 19
6 Technology specific requirements . 20
6.1 OSGI service platform . 20
6.1.1 Essentials . 20
6.1.2 Architecture . 21
6.1.3 OSGI specific requirements . 21
Annex A (normative): JAVA™ compatibility guidelines . 25
A.1.1 Bytecode compatibility . 25
A.1.2 JAVA™ runtime . 25
A.1.3 Extensions . 25
Annex B (normative): Resource control guidelines for JAVA™ . 26
ETSI
4 ETSI TS 103 426 V1.1.1 (2016-11)
B.1.1 RAM . 26
B.1.2 CPU sharing . 26
B.1.3 Devices . 27
B.1.4 Running JAVA™ threads . 27
B.1.5 Open TCP connections . 27
B.1.6 Conclusions . 27
Annex C (informative): Bibliography . 28
History . 29

ETSI
5 ETSI TS 103 426 V1.1.1 (2016-11)
List of figures
Figure 1: Entities, Roles and Relations between them .12
Figure 2: Home Gateway Architecture Model .13
Figure 3: Component view of an OSGi based Home Gateway .21

ETSI
6 ETSI TS 103 426 V1.1.1 (2016-11)
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 (https://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 ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M), as result of the PAS process for document HGI-RD048 developed by the Home
Gateway Initiative.
The Home Gateway Initiative, a non-profit organization closed on June 2016, produced guidelines, requirements
documents, white papers, vision papers, test plans and other documents concerning broadband equipment and services
which are deployed in the home.
HGI worked on Specifications for home connectivity and Services enablement, in particular to encompass a delivery
framework for Smart Home services. The defined architecture includes support for a standard, general purpose software
execution environment in the HG (for third party applications), API definitions, device abstraction, and interfacing with
Cloud based platforms.
The HGI's methodology ensured that projects undertaken reflected items of strong interest to the Broadband Service
Providers (BSPs), as well as brought in opportunities at every stage for vendor input, suggestions and participation.
® ® ®
NOTE: Silicon Labs , Java™, ProSyst , Makewave are suitable products available commercially. This
information is given for the convenience of users of the present document and does not constitute an
endorsement by ETSI of this these product).
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).
ETSI
7 ETSI TS 103 426 V1.1.1 (2016-11)
1 Scope and purpose of the present document
1.1 Abstract
The present document, originally developed as HGI-RD048v2, contains requirements regarding modular software
deployments on the home gateway. These requirements form the HGI's "Open Platform 2.1".
Under the Open Platform 2.1 requirements, modular software applications have to run in a dedicated virtual execution
environment to avoid conflicts and interferences with the natively installed software. The present document reflects
generic requirements valid for any modular execution platform, as well as technology-specific requirements for OSGi
technology. Other technology-specific requirements could be developed in the same way as the OSGi requirements, in
conjunction with the generic requirements.
The present document, HGI_RD048v2, is an update of, and supersedes, HGI's already-published HGI-RD48v1 which
specified the requirements for Open Platform 2.0. HGI-RD048v2 specifies Open Platform 2.1 that primarily updates
external references and makes various corrections.
HGI-RD48v1 itself was an updated version of HGI-RD008 [i.20], HG Requirements for a Software Execution
Environment, which was known in the HGI community as "SWEX". Besides updates on referred standards, HGI-
RD048v1 added basic requirements to support USB based hardware extendibility for Smart Home services, details for
usage for OSGi technology and system clock management.
1.2 Scope and purposes
Service delivery to residential customers beyond triple play requires the integration of home devices and appliances
with cloud infrastructures. Such integration often requires new software in the home network, but the variety of
available technologies makes this difficult. In order to achieve the next level of service integration, there is a need for
software flexibility on the main operator-controlled device in the home, the home gateway.
New software can be added to the HG by doing complete firmware upgrades; however doing this may cause significant
problems. Each new version need to be fully tested, and different versions are required for different application areas.
Maintaining different versions of firmware for several HG models would further complicate configuration management.
There is also the considerable overhead of upgrading large numbers of HGs.
The solution discussed in the present document integrates a software execution platform, called by HGI Open Platform
2.1, into the firmware, allowing the installing, updating, uninstalling, starting and stopping of additional software
modules, while the underlying firmware image remains untouched.
The present document contains a home gateway software modularity architecture specification based on function
blocks, a role and entity model, and derives requirements for the home gateway. Requirements are specified not only for
a software execution platform, but also for an API that allows software modules to access the core home gateway
functions.
The requirements section is divided into two areas: generic requirements, which apply to any technology used as
software execution platform, and specific requirements for selected technologies. Specific requirements are only given
for OSGi technology in the present document.
1.3 What is new compared to HGI-RD008 and to RD-048v1?
1.3.1 RD-048v1 compared with RD-008 [i.20]
• Addition of Smarthome related low-level requirements, especially in terms of support of USB based hardware
extendibility.
• Detailed requirements for system clock synchronization.
• Detailed OSGi requirements: Many requirements have been detailed for clarification and precision reasons.
• Reference to Broadband Forum TR-181 [i.4] rather than the outdated TR-098 [i.5].
ETSI
8 ETSI TS 103 426 V1.1.1 (2016-11)
• Reference to OSGi R4 version 4.2 ([i.9] and [i.10]) and higher rather than 4.0 and higher.
• Collation of Java™ related requirements into HGI/Minimum-1.0 Java™ Profile.
1.3.2 RD-048v2 compared with RD-048v1
• Streamlined text.
• Modified figures to reflect text consistency.
• Streamlined wording of requirements.
• Updated references to OSGi and Java™ JRE version.
• Updated Java™ related requirements to Java™ 8 compact1 profile.
• Requirements that in RD-048v1 referred to OSGi Service Platform Specification Release 4.2 (Core [i.9] and
Compendium [i.10]) now refer to Release 4.3 (Core [i.11], and Residential [i.12]), 5 (Core [i.13]) and 6
(Core [i.14], and Residential [i.15]).
• Re-inserted references to TR-098 [i.5] along with TR-181 [i.4] since TR-098 continues to be deployed.
1.4 Relationship with HGI residential profile
The present document contains requirements over and above those in the HGI Residential Profile [i.1], to support the
software module execution environment. All requirements of the HGI Residential Profile still apply.
Some of the original functionalities defined in the HGI Residential Profile [i.1] may be suitable for implementation as
software modules, in particular those that have some of the following characteristics:
• Control functions (rather than data plane).
• Functions which can be run on different HG models.
• Functions with different versions.
The following list gives examples of functionalities from the HGI Residential Profile, which may be amenable to
implementation as software modules (see definitions in [i.1]):
DHCP Server - A DHCP server is a fairly standalone application, handing out local IP addresses and managing their
lifetime. The information gathered by the DHCP server can easily be given to other (authorized) modules (MAC
addresses, DHCP options).
UPnP IGD - A UPnP IGD [i.2] service for example would be easy to implement on top of an OSGi service platform,
because OSGi provides a standardized UPnP stack [i.2], given that there is an interface to manage the lower level
functions of the HG.
Local Management Remote User Interface - An operator might see some advantage in having the same
implementation of the LM Remote UI for different models of HGs, to facilitate a consistent corporate design, and
having only one code base to maintain.
DynDNS Client - A DynDNS client is also a fairly stand-alone application (registering a public IP address at a certain
domain server). Having it as a module has the advantage that several registration protocols for different dynamic DNS
services can be supported.
NTP Client - Needs access to system date and time management of the HG.
However, some functions defined in the HGI Residential Profile are not recommended to be done as modules. These
include the networking features (e.g. routing, bridging, NAT), the basic HG remote management and the firmware
upgrade from the RMS (Remote Management System). The common feature of these is that these functions are
normally preserved in the case of an execution environment fault. Further, these functions are generally already
available in native software, and gain a performance advantage from direct interaction with the hardware.
ETSI
9 ETSI TS 103 426 V1.1.1 (2016-11)
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
https://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.
Not applicable.
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] HGI-RD001-R2.01: "Home Gateway Technical Requirements: Residential Profile V1.01".
[i.2] UPnP IGD 2.0: "Internet Gateway Device (IGD) v2.0".
NOTE: See http://upnp.org/specs/gw/igd2/.
[i.3] ETSI TS 103 424: "Publicly Available Specification (PAS); Smart Machine-to-Machine
communications (SmartM2M) Home Gateway Initiative RD036-Smart Home architecture and
system requirements".
[i.4] BBF TR-181: "Device Data Model for TR-069".
NOTE: See https://www.broadband-forum.org/technical/trlist.php?key=1.
At the time of writing two issues of TR-181 are available. Issues in BBF terminology stand for non-
backward-compatible updates, so in fact TR-181i1 and TR-181i2 describe independent data models and
requirements are intended to specify compliance at least with one issue. Amendments indicate backward
compatible changes (except for DEPRECATED and OBSOLETED features) so it would be enough to
check compliance with the most recent Amendment for each issue. Corrigenda indicate minor revisions.
[i.5] BBF TR-098: "Internet Gateway Device Data Model for TR-069".
NOTE: See https://www.broadband-forum.org/technical/trlist.php?key=1.
[i.6] BBF TR-069 Amendment 5: "CPE WAN Management Protocol".
NOTE: See https://www.broadband-forum.org/technical/trlist.php?key=1.
ETSI
10 ETSI TS 103 426 V1.1.1 (2016-11)
[i.7] BBF TR-104: "DSLHome Provisioning Parameters for VoIP CPE".
NOTE: See https://www.broadband-forum.org/technical/trlist.php?key=1.
At the time of writing two issues of TR-104 are available. Issues in BBF terminology stand for non-
backward-compatible updates, so in fact TR-104i1 and TR-104i2 describe independent data models and
requirements are intended to specify compliance at least with one issue. Amendments indicate backward
compatible changes (except for DEPRECATED and OBSOLETED features) so it would be enough to
check compliance with the most recent Amendment for each issue. Corrigenda indicate minor revisions.
[i.8] BBF TR-157 Amendment 10: "Component Objects for CWMP".
NOTE: See https://www.broadband-forum.org/technical/trlist.php?key=1.
[i.9] "OSGi Service Platform Core Specification Release 4.2".
NOTE: See https://osgi.org/download/r4v42/r4.core.pdf.
[i.10] "OSGi Service Platform Compendium Specification Release 4.2".
NOTE: See https://osgi.org/download/r4v42/r4.cmpn.pdf.
[i.11] "OSGi Service Platform Core Specification Release 4.3".
NOTE: See https://osgi.org/download/r4v43/osgi.core-4.3.0.pdf.
[i.12] "OSGi Service Platform Residential Specification Release 4.3".
NOTE: See https://osgi.org/download/r4v43/osgi.residential-4.3.0.pdf.
[i.13] "OSGi Service Platform Core Specification Release 5".
NOTE: See https://osgi.org/download/r5/osgi.core-5.0.0.pdf.
[i.14] "OSGi Service Platform Core Specification Release 6".
NOTE: See https://osgi.org/download/r6/osgi.core-6.0.0.pdf.
[i.15] "OSGi Service Platform Residential Specification Release 6".
NOTE: See https://osgi.org/download/r6/osgi.residential-6.0.0.pdf.
[i.16] "Java 8 For Embedded, compact1 profile".
NOTE: See https://docs.oracle.com/javase/8/docs/technotes/guides/compactprofiles/compactprofiles.html.
TM
[i.17] JSR 80: "Java USB API".
NOTE: See https://jcp.org/ja/jsr/detail?id=80.
TM
[i.18] JSR 180: "SIP API for J2ME ".
NOTE: See https://jcp.org/ja/jsr/detail?id=180.
[i.19] "Java SE Embedded 8 vs. Java ME CDC Comparison".
NOTE: See http://www.oracle.com/technetwork/java/embedded/resources/tech/java-se-emb-vs-java-me-cdc-
2157146.html.
[i.20] HGI-RD008: " Requirements for Software Modularity on the Home Gateway".
NOTE: See http://www.homegatewayinitiative.org/userfiles/file/downloads/RD-008-R3.pdf.
ETSI
11 ETSI TS 103 426 V1.1.1 (2016-11)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Gateway Operator (or just operator): Primary responsibility of the Gateway Operator is to control who is allowed to
deploy services to the Service Platform in question i.e. control which Service Deployment Managers are allowed to
manage the particular Service Platform. In addition to this, the Gateway Operator can also manage other functions
related to a specific Service Platform instance.
Home Gateway (HG): hosts one or more Service Platforms
(Home Gateway) Service Platform (HG_SP): Primary function of the Home Gateway Service Platform is to manage
the execution lifecycle of Service Modules. The Service Platform is capable of dynamically loading, activating,
deactivating, updating, and unloading the Service Modules. The HG_SP is part of the HG_EE as defined in clause 4.2.
Network Provider: Provides and manages wide area network connectivity between the Service Platform and other
parties, which include the Gateway Operator and other Service Providers. In the case where the Service Platform is
connected via the Internet, the Network Provider also supplies the Internet Service Provider (ISP) functionality.
Service Application: Set of modules and configuration that collectively implement a specific function or set of
functions, possibly across several Service Platforms. The Service Application concept is only relevant to the Service
Deployment Manager.
Service Customer: Subscribes to services and pays the charges that are incurred using those services.
Service Deployment Manager: Acts on behalf of the Service Provider and deploys Service Modules on the Service
Platform. The Service Deployment Manager manages all aspects related to the life cycle of Service Applications that
are external to the Service Platform.
Service Module (or just module): downloadable, packaged collection of resources and/or code needed to provide a
specific function
Service Provider: Is a business entity. The Service Provider supplies the necessary means to provide the business
related support of a specific Service Application. The Service Provider is also responsible for delegating the task of
service deployment to the Service Deployment Manager.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACS Auto Configuration Server
CWMP CPE Wan Management Protocol
RMS Remote Management System
4 Architecture
4.1 Roles and entities
This clause defines operational roles and entities for an execution environment on the HG.
The HGI roles of "Broadband Service Provider" (BSP) and "Application Service Provider" (ASP) as defined in [i.1]
may apply to several of the following roles, but both certainly apply to the "operator" role. For example, a BSP might
take the role of the Service Deployment Manager, or chose to delegate this function to another company. It is up each
BSP to decide which roles to take and which to delegate.
ETSI
12 ETSI TS 103 426 V1.1.1 (2016-11)
Figure 1 depicts roles (depicted as round-cornered rectangles) and entities (regular rectangles). Roles are individual
persons or legal entities (e.g. companies), while entities are machines/software.

Figure 1: Entities, Roles and Relations between them
The various roles and entities are defined in clause 4.2.
4.2 Entities in the open platform 2.1 - enabled home gateway
Entities in the Open Platform 2.1 enabled Home Gateway are depicted in Figure 2. This is the reference scheme for the
Home Gateway Software Architecture [i.3]. The HG consists of the core functions (HG_Core) plus one or more HG
Execution Environments (HG_EE), each of them including a Service Platform (HG_SP) and software modules, all
entities as defined below:
• HG Core (HG_Core) - The HG_Core uses an operating system (OS). On this operating system runs the HG
native software that provides some or all of the home gateway functions as defined in the HGI Residential
Profile [i.1]. Native drivers give direct access to hardware modules. The combination of the Home Gateway
hardware, operating system, native software and drivers constitutes the HG_Core.
• HG Execution Environment (HG_EE) - The HG_EE is the combination of the Service Platform (HG_SP)
and the Service Modules. The Service Platform (as defined in clause 4.1) runs on the HG_Core, and is used to
provide flexible application software module execution and management. The platform allows life cycle
control (install, start, update, stop and uninstall) of provider-managed software modules. There may be more
than one HG_EE running on top of the HG_Core .
• HG Application Programming Interface (HG_API) - The HG_API is provided to modules running in the
HG Execution Environment (HG_EE), giving standardized access to residential gateway functions that are
defined in the HGI Residential Profile. The minimum function set of the HG_API shall provide access to the
applicable parameters defined in TR-181 [i.4] or TR-098 [i.5], profiled for the actual HG features. The
HG_API can be implemented as part of the HG_Core and/or as modules running in an HG_EE; typically it is
implemented as one or more modules. Access to the HG_API shall be explicitly granted by the operator for
each module on a per function basis.
ETSI
13 ETSI TS 103 426 V1.1.1 (2016-11)
• Management Agent (MA) - The MA is a piece of software running on the HG and using the CWMP protocol
[i.6] to handle commands from a RMS (Remote Management System) to the HG. Via CWMP and the MA, the
RMS can set on and get parameters from the HG or execute HG functions. Moreover, by means of CWMP the
MA is able to send notifications from the HG back to the RMS. No assumption is made in the present
document about the internal HG implementation of the MA. It could be part of the HG_Core, or one or more
modules running in the HG_EE, or a hybrid implementation.
4.3 Home gateway software architecture
This clause describes the software architecture for the integration of a Service Platform into an HG. The architecture is
generic in the sense that applies to any chosen Service Platform technology.
4.3.1 Essentials
• An HG_API shall be defined for any specific Service Platform technology. All HGs using that specific
technology shall implement the HG_API defined for that technology.
• There are no restrictions on how modules are implemented other than those defined by the chosen Service
Platform technology.
• Any modules intended to be portable across different HG products shall not access any HG internal software
interface outside of the HG_EE.
• Implementation of the HG_API is vendor-specific and not part of the present document.
4.3.2 Details
The HG_EE runs on top of the HG_Core. Modules run on top of the Service Platform and are able to communicate with
each other to use each other's functions, if they are authorized to do so.
Using functions other than those provided by the Service Platform is allowed (e.g. to provide direct access to the
HG_Core for vendor-specific modules), although doing so would probably limit the portability of a module.

Figure 2: Home Gateway Architecture Model
The HG_SP has a number of functional blocks:
• Lifecycle Management - The Service Platform executes Service Modules and controls their execution. The
lifecycle management function of the Service Platform provides APIs to start and stop these modules.
ETSI
14 ETSI TS 103 426 V1.1.1 (2016-11)
• Deployment Management - Modules are packaged in a format defined by the Service Platform technology
and can be downloaded from remote repositories accessible through URLs. According to the URL, the proper
protocol handler shall be made available (e.g. HTTP, HTTPS or FTP). Modules can then be installed which
may imply unpacking on local storage or other specific one- time tasks.
• Registry - Module functions can be exposed through a local repository interface, which is specific to the
Service Platform technology. The registry holds up-to-date information on which module is installed, which
module is running, etc. Modules can use the registry to lookup functions implemented by other modules.
• Dependency Management - A module can depend on other modules to work correctly, e.g. on resources
being present or services running. The dependency management function takes care of these relations, resolves
dependencies and cleans up when a module is uninstalled.
4.4 Access to smart home non IP networks
There are three common models to address appliances in non-IP networks (e.g. switches, dimmers, sensors).
Some systems allow an external gateway to be attached to the HG and then be accessed over IP-based protocols (such
as HTTP) in order to perform actions and queries on appliances connected to the external gateway using other
communication protocols.
Another option is to integrate a radio module into the HG. Usually, these interfaces are connected through a UART
connector and exposed to the operating system as serial interfaces. Since the application layer communication on this
serial interface is proprietary or technology-specific, some kind of driver software shall be included into the HG's
software stack by the provider of the serial interface.
Quite common is also the approach to attach an interface through USB ports. Most of the systems provide USB dongles
that implement some type of virtual serial interface (a serial interface tunnelled through USB). Although there are USB
class standards like Communication Device Class and Human Interface Device which could be used for virtual serial
ports, many USB dongles use chips which make use of non-standard USB classes. However, USB dongles
implementing virtual serial ports are also exposed as serial interfaces to the OS. While the IP gateway option does not
require anything from the HG but IP based communication, the latter two options require the HG service platform to:
a) support access to serial line communication; and
b) provide an API for USB port management.
4.5 Remote management
4.5.1 Essentials
• The remote management protocol for HG_EE is CWMP [i.6] with its related data models TR-181 [i.4] or
TR-098 [i.5].
• There is only 1 management entity for any given HG_EE (see role model in Figure 1).
• LAN-side management (by e.g. the customer) is not allowed for HG_EE.
• Management/configuration of the service aspect of modules is out of scope for the present document.
• Regular download protocols for modules are HTTP and HTTPS.
4.5.2 Details
Management of the software configuration of an HG is under the control of a (single) Gateway Operator. This includes
the approval of any software before it is installed on to the execution environment.
Third party service providers are therefore dependent on the Gateway Operator for the installation of modules to deliver
their services. This means there is a single management entity, and so this entity is able and responsible to resolve any
resource conflicts.
ETSI
15 ETSI TS 103 426 V1.1.1 (2016-11)
An execution environment for software modules is just another aspect of an HG that needs to be remotely managed. As
HGI has agreed to specify the CWMP [i.6] protocol for HG management, it is highly advisable that the management of
the execution environment be based on the CWMP protocol [i.6] and related data model (TR-181 [i.4], TR-098 [i.5]).
The present document does not standardize the configuration of service applications. The configuration of service
applications can be carried out in any appropriate way, e.g. by a local user interface, a network connection to a third
party backend, or through the RMS of the operator.
A crucial aspect of the entire software module management is security and access control. E.g. third party service
applications should not be allowed to perform any life cycle operations. The RMS should have exclusive control and
responsibility about which modules to install, uninstall or update.
The HG is not able and not in charge to determine the order of install, uninstall and update actions, because it does not
know the semantic dependencies between modules. This definition implies that the RMS shall only issue requests to the
HG for uniquely identified modules. For example, an RMS shall not issue a single request to the HG to update "all"
modules (or other "wildcard" like requests), but shall specify each module separately. On the other side, the HG shall
deny any RMS issued request that cannot be resolved to a well-defined action.
4.5.3 Issues with firmware updates and software module management
If the software execution platform is part of a device's firmware, then a firmware update probably contains an empty
execution platform, and therefore it is probably necessary to reinstall all needed modules and configurations. On a large
scale, considering millions of devices and hundreds of applications per device, a firmware update could lead to strong
scalability challenges on the RMS side (ACS if CWMP is used), since not only firmware images have to be
downloaded, but also all the modules that were installed before the update.
Moreover, a firmware update might not necessarily change anything in the execution environment configuration. In
order to avoid such scalability issues, the HG should assure the following points:
• Software modules should be kept across firmware updates.
• Software modules should only be downloaded if they are not already downloaded onto the HG's memory.
• Same applies to module configuration data.
These requirements can have hardware and software implications (like e.g. more flash memory to cache software
modules).
5 Generic requirements
The following clauses contain high-level requirements to make the HG execution environment for software modules
reliable, manageable and useable to application developers. Requirements in each section apply to one of:
• HG (i.e. may be implemented anywhere in HG).
• HG_Core.
• HG_EE (i.e. may be implemented anywhere in HG_EE).
• The HG_SP function of the HG_EE.
5.1 Basic requirements
Requirements in this clause could be implemented in the HG_Core or the HG_EE, or both.
ETSI
16 ETSI TS 103 426 V1.1.1 (2016-11)
Table 1
N° Requirement
OP2.0-1
The HG SHALL have an internal system clock to provide the date and time of day. See note.
OP2.0-2 The HG SHALL support synchronisation of its internal system clock with an external time server via its
broadband connection. The synchronization interval SHALL be configurable so that the time deviation is less
than 10 seconds.
OP2.0-3 A user interface to set time and date locally SHALL only be made available to the end user when network based
time sync is lost.
OP2.0-4 The HG_Core SHOULD support the installation of additional USB drivers as kernel modules.
OP2.0-4a The HG_SP SHOULD support the installation of additional USB drivers.
OP2.0-5 The HG_Core SHALL provide a way to place a strict upper limit on the CPU load used by the HG_EE. This limit
applies only when the HG_Core needs the resources.
OP2.0-6 The HG_Core SHALL provide a way to strictly limit the runtime memory used by the HG_EE.
NOTE: Valid date and time are crucial for the validation of certificates.

The following requirements enable the HG to support additional USB classes, for example (W)HAN technology
interfaces.
Table 2
N° Requirement
OP2.0-7 The HG_Core SHOULD include USB class drivers for Human Interface Device (HID).
OP2.0-8 The HG_Core SHOULD include USB class drivers for Communications Device Class (CDC). See note 1.
OP2.0-9 The HG_Core SHOULD include drivers for FTDI Virtual Com Ports. See note 2.
OP2.0-10
If the HG_Core supports OP2.0-9, then it SHALL support configuration of the FTDI VCP drivers in terms of a
list of supported USB Vendor Identifiers and Product Identifiers. This list SHALL provide at least 100 entries.
All configured Vendor/Product identifiers SHALL be attached to the FTDI device driver. Reconfiguration of the
FTDI driver SHOULD NOT require a reboot of the HG. ®
OP2
...