ImageVerifierCode 换一换
格式:PDF , 页数:29 ,大小:352.82KB ,
资源ID:740107      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-740107.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(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.pdf)为本站会员(medalangle361)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

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.pdf

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1