ETSI TS 103 426-2016 Publicly Available Specification (PAS) Smart Machine-to-Machine communications (SmartM2M) Home Gateway Initiative RD048-HG Requirements For HGI Open Platform 2_1.pdf

《ETSI TS 103 426-2016 Publicly Available Specification (PAS) Smart Machine-to-Machine communications (SmartM2M) Home Gateway Initiative RD048-HG Requirements For HGI Open Platform 2_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 103 426-2016 Publicly Available Specification (PAS) Smart Machine-to-Machine communications (SmartM2M) Home Gateway Initiative RD048-HG Requirements For HGI Open Platform 2_1.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、 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 CAUTION The present document has been submitted to ETSI as a PAS produced by HGI and approved by the ET

2、SI 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 warranti

3、es 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. TECHNICAL SPECIFICATION ETSI E

4、TSI TS 103 426 V1.1.1 (2016-11)2 Reference DTS/SMARTM2M-103426 Keywords GATEWAY, Home Gateway, intelligent homes 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

5、 (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,

6、 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,

7、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 enableme

8、nt, 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 platfo

9、rms. The HGIs 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, Makewaveare suitable product

10、s 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“, “wi

11、ll 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 ETSI TS 103 426 V1.1.1 (2016-11)7 1 Scope and purpose of the present document 1.1 Abstract The present document, originally developed as HGI-R

12、D048v2, contains requirements regarding modular software deployments on the home gateway. These requirements form the HGIs “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 inte

13、rferences 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 requirem

14、ents, in conjunction with the generic requirements. The present document, HGI_RD048v2, is an update of, and supersedes, HGIs 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 mak

15、es 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 extendib

16、ility 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 ne

17、w 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 H

18、G 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 configura

19、tion 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 stopp

20、ing 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 sp

21、ecified 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 re

22、quirements 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

23、 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 ETSI TS 103 426 V1

24、.1.1 (2016-11)8 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 o

25、f 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

26、 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 Profil

27、e 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

28、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 modu

29、les (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

30、 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 i

31、n 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 serv

32、er). 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

33、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.

34、Further, these functions are generally already available in native software, and gain a performance advantage from direct interaction with the hardware. ETSI ETSI TS 103 426 V1.1.1 (2016-11)9 2 References 2.1 Normative references References are either specific (identified by date of publication and/

35、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 expec

36、ted 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

37、 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 (inc

38、luding 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 reg

39、ard 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-Mac

40、hine 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

41、 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

42、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 Managemen

43、t Protocol“. NOTE: See https:/www.broadband-forum.org/technical/trlist.php?key=1. ETSI ETSI TS 103 426 V1.1.1 (2016-11)10 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 a

44、re 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

45、 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 Platfor

46、m 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/dow

47、nload/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 S

48、ervice 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:/ i.17 JSR 80: “JavaTMUSB API“. NOTE: See https:/jcp.org/ja/jsr/detail?id=80. i.18 JSR 180: “SIP API for J2METM“. NOTE: See https:/jcp.org/ja/jsr/detail?id=180. i.19 “Java SE Embedded 8 vs. Java ME CDC Comparison“. NOTE: See http:/ i.20 HGI-RD008: “ Requirements for Software M