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

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






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.

---------------------- Page: 1 ----------------------
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.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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

---------------------- Page: 2 ----------------------
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

---------------------- Page: 3 ----------------------
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

---------------------- Page: 4 ----------------------
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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
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

---------------------- Page: 8 ----------------------
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

---------------------- Page: 9 ----------------------
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

---------------------- Page: 10 ----------------------
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 conc
...