在前面的文章中我们描述的M2M架构被设计为横向架构，它们的服务层方法对于任何种类的M2M应用来说都是通用的。然后，对于真正的实现而言，有必要与通用的标准的目标保持一些距离，并支持受现实约束的特定的应用。本节专门针对以智能家居网关为中心的参考架构，该架构是可以联合智能家居应用开发商，制造商，运营商和服务提供商的HGI (HGI：Home Gateway Initiative)行业组织进行标准化工作。在这个特定的智能家庭领域需要一种抽象层以及对语义的需求使其与ETSI M2M / oneM2M标准化机构合作。
正如我们前面的文章中所说，M2M服务层标准最初由ETSI M2M制定的，现在由 oneM2M推动M2M标准化以适用于任何M2M应用领域。特别是，M2M可以在家庭环境中实现多样化的有前途的服务。
一些示例性应用包括涉及不同类型的领域，包括：智能电网(与家用电器能耗相互作用的需求和响应相关的应用场景)，医疗保健，家庭自动化和安全性(例如烟雾检测或者入侵检测应用场景)等，这些应用中包括不同类型的行动器，但是需要一些相似类型的功能(认证，识别，访问权限控制，设备管理，存储和转发数据，计费记录等)来运行其应用程序。
图1展示了可由M2M应用提供商利用的M2M标准提供的一些功能性(在 ETSI M2M标准组织的术语中称之为“服务能力(service capabilities)”或者在 oneM2M标准组织的术语中称之为“通用服务功能(common service functions)”)的示例，因为这些功能大多数都在M2M2应用提供商的核心业务范围之外，这样应用提供商可以专注于他们的核心业务的发展。在该图中，SC在网络域上列出，并给出带有“N”前缀的缩写，用于表示在NSCL(NSEC，NRAR等)上的SCs(service capabilities);而相同的在网关SCL上的SCs可以使用“G”前缀而不是“N”标注，如GSEC，GRAR等或者在设备SCL上的SCs用前缀“D”标注，如DSEC，DRAR等。
图1、为不同的M2M应用提供商提供的通用的功能框架
我们看到的智能家居示例中，为了允许应用在不同的服务提供商之间共享，预计将需要通过标准化的APIs来提供最小的功能集，包括：
·认证
·访问权控制
·从家中的设备访问订阅的某些事件的应用程序
·发生事件时通知应用
·有关在智能家居环境中正确运行应用所需的软件配置信息
·配置硬件和应用
这些功能通常是由上面所示的ETSI M2M框架提供的通用SC的子集。当考虑如何在家庭网关服务层上实例化时，可以特别注意到ETSI M2M的一些最低限度的功能，如图2所示(智能家居案例被认为对于智能家居案件至关重要的功能被写在蓝盒中，而与智能家居的最低优先级的功能则放在白盒子中)。在该图中的实例称为“M2M代理(M2M Agent)”。
图2、可以在家庭网关GSCL上实例化的一些ETSI M2M服务功能的示例
ETSI M2M使用本地API(dIa)将允许传统本地网络访问M2M代理，而从HG(家庭网关)向云(mId)使用ETSI M2M API则允许我们通过mIa云API解决第三方应用程序。
通过更加具体地看待全球智能家居服务架构，可以看到如图2所示它由三个主要部分组成的：
1.房屋内的“家庭”部分，涉及处理本地应用程序，嵌入在设备和/或网关中;在这里，我们可以发现设备制造商和家庭自动化专家(例如，用于监控百叶窗或者监控照明灯光)，以提供 ad hoc(点对点)智能家庭子系统。
2.房屋和外部世界之间的边界部分，可能包括(智能)家庭网关与远程服务平台之间的接口。
3.“云”部分，其中远程应用程序可以通过与将远程应用程序参数转发到寻址的家庭设备中的服务平台的接口进行目标定位家庭设备。
图3、智能家居的整体架构。
虽然在上面的图3中已经引用了一些标准，但它们并不是智能家居领域唯一可以看到的标准。相反，它强调了今天正在寻求独立于执行环境的智能家居的通用工具的组织之间的讨论，以及为部署智能家居服务而选择的连接技术。
从智能家居的角度来看，当考虑到存在资源有限的设备以及互操作性方面的问题时家庭内部部分(in-home part)具有特定的要求，这一点对于获得更愿意投资具有根据自身未来需求演进保障的可持续解决方案的最终用户的信心尤为重要。
