CN109997114B - 用于通用互通和可扩展性的服务层资源管理 - Google Patents

用于通用互通和可扩展性的服务层资源管理 Download PDF

Info

Publication number
CN109997114B
CN109997114B CN201780071831.XA CN201780071831A CN109997114B CN 109997114 B CN109997114 B CN 109997114B CN 201780071831 A CN201780071831 A CN 201780071831A CN 109997114 B CN109997114 B CN 109997114B
Authority
CN
China
Prior art keywords
resource
service layer
information
customized
interworking
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201780071831.XA
Other languages
English (en)
Other versions
CN109997114A (zh
Inventor
Q·李
D·N·希德
W·R·弗林四世
C·M·姆拉丁
王崇刚
R·迪吉洛拉莫
陈卓
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Convida Wireless LLC
Original Assignee
Convida Wireless LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Convida Wireless LLC filed Critical Convida Wireless LLC
Priority to CN202311218363.8A priority Critical patent/CN117170876A/zh
Publication of CN109997114A publication Critical patent/CN109997114A/zh
Application granted granted Critical
Publication of CN109997114B publication Critical patent/CN109997114B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

提供了轻量级的动态机制以支持服务层互通和资源可扩展性。例如，本文公开的一种机制包括定义新的服务层(SL)资源定义注册过程，该过程允许指定服务层资源的定制属性以表示第三方技术资源。本文公开的第二种机制包括定义新的SL数据模型映射注册过程以将服务层资源映射到第三方数据模型并向服务层提供新的互通的重定标指示符。另外，本文公开的第三种机制包括定义SL通用互通过程，以基于由数据模型映射提供的互通的重定标指示符智能地将请求朝着互通的资源重定标。

Description

用于通用互通和可扩展性的服务层资源管理
对相关申请的交叉引用
本申请要求于2016年10月7日提交的美国临时专利申请No.62/405,534的权益，其全部内容通过引用并入本文。
背景技术
诸如oneM2M之类的当前服务层互通架构提供了互通(interwork)来自第三方技术的节点或设备的各种方案。这些方案包括：1)第三方技术资源(诸如用于LWM2M对象的资源)到服务层资源的标准映射；2)透明互通，其中非oneM2M数据模型被封装在oneM2M资源内，3)重定标(retarget)互通，其中映射的接口作为oneM2M资源暴露，并且当访问那个资源时，请求被重定标，以及4)非oneM2M数据模型互通的语义的完全映射。每种方案都有其局限性。对于标准映射方案，第三方技术资源在标准化期间被映射到服务层资源。这种映射处理难以维护，并且在轻量级机器对机器(LWM2M)对象的情况下，它是不完整的、令人困惑的或完全缺乏的。透明和重定标互通的两种方法完全隐藏了互通设备的数据模型，这限制了针对感兴趣的领域内的应用使用那些资源。非oneM2M数据模型互通的语义的完全映射提供了资源的一对一映射，但是在存在许多不同类型的设备时不能很好地扩展。
发明内容
为了使服务层互通普遍且高效地工作，互通设备的数据模型应当暴露给所有应用，并且应当存在动态机制来添加或更新互通设备的数据模型的资源定义和映射。这些能力将使服务层架构能够将各种垂直市场带到单个水平平台中。此外，可以将新的资源类型添加到服务层以实现可扩展性。本文公开了用于支持服务层互通和资源可扩展性的轻量级动态机制。
例如，本文公开的一种机制包括定义新的服务层(SL)资源定义注册过程，所述过程允许指定服务层资源的定制属性以表示第三方技术资源。作为新功能的一部分，引入了用于管理资源定义的附加过程。
本文公开的第二种机制包括定义新的SL数据模型映射注册过程以将服务层资源映射到第三方数据模型并向服务层提供新的互通的重定标指示符。用于管理资源定义的相同过程也可以用于管理数据模型映射。
另外，本文公开的第三种机制包括定义SL通用互通过程，以基于由数据模型映射提供的重定标指示符智能地将请求朝着互通的资源重定标。
提供本发明内容是为了以简化的形式介绍一些概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或所有缺点的限制。
附图说明
可以从以下结合附图的示例给出的描述中获得更详细的理解，其中，其中：
图1图示了示例oneM2M服务层架构；
图2示出了示例oneM2M资源；
图3A和3B示出了示例oneM2M XML Schema Definition(XSD，XML模式定义)文档；
图4示出了示例oneM2M互通架构；
图5示出了示例轻量级M2M(LWM2M)架构；
图6图示了涉及由诸如oneM2M之类的服务层标准定义的通用互通的示例用例；
图7示出了映射到四个oneM2M mgmtObj资源的LWM2M设备对象；
图8图示了用于服务层通用互通的示例端到端过程；
图9示出了示例服务层资源定义文档注册过程；
图10示出了示例简化服务层资源定义发现过程；
图11示出了示例服务层资源定义激活过程；
图12示出了示例服务层资源定义停用过程；
图13示出了示例服务层数据模型映射文档注册过程；
图14示出了示例通用服务层互通过程；
图15图示了创建新的oneM2M公共服务功能(Common Services Function，CSF)以及更新现有CSF的示例；
图16A和16B示出了示例oneM2M资源定义文档；
图17示出了用于互通代理实体(Interworking Proxy Entity，IPE)的示例oneM2M数据模型映射文档；
图18示出了用于服务层的示例oneM2M数据模型映射文档；
图19示出了用于让oneM2M CSE支持新的特化<mgmtObj>资源的示例过程；
图20图示了示例通用互通过程；
图21示出了<flexContainer>工作示例；
图22示出了涉及两个供应商的互通示例；
图23图示了涉及多个LWM2M服务器的智能重定标；
图24图示了示例用户接口；
图25A是示例机器到机器(M2M)、物联网(IoT)或物联网(WoT)通信系统的系统图，其中可以实现一个或多个公开的实施例；
图25B是可以在图25A中所示的M2M/IoT/WoT通信系统内使用的示例架构的系统图；
图25C是可以在图25A和25B中所示的通信系统内使用的示例通信网络装置(诸如M2M/IoT/WoT设备、网关或服务器之类)的系统图；以及
图25D是示例计算系统的框图，其中可以实施图25A和25B的通信系统的节点。
具体实施方式
术语和定义
本部分不旨在用于限制要求保护的主题的范围，也不旨在用于将下面讨论的任何术语的范围限制于所提供的定义。
互通是指第二技术的域内的外部技术的工作。例如，LWM2M可以互通到oneM2M中。通常，互通需要在两种技术之间进行某种形式的协议转换和数据模型映射。
LWM2M被认为是与SL架构互通的第三方技术。它是一种轻量级客户端-服务器协议，被定义为用在设备的服务启用和设备管理中，所述设备通常在本质方面受限于有限的处理(CPU、MCU)和存储(RAM、ROM)能力。
可以用名称resourceName(资源名称)来表示SL资源的名称。这个约定与oneM2M中使用的约定相同。
资源激活是使得资源定义可供服务层使用的SL处理。该处理可以包括认证请求者、从资源定义文档中提取信息以创建针对资源/资源类型的模式文档、更新支持的资源类型属性以用于发现目的，等等。
资源停用是从SL储存库移除模式文档，因此未来不能创建基于移除的模式的资源的SL处理。仅当资源类型不再使用且正在退役时，才会执行这个处理。
资源定义是详细描述服务层资源类型的文档。该文档包括诸如以下的信息：资源类型、特化(specialized)资源类型的名称(如果存在的话)(例如，在oneM2M中，电池是mgmtObj资源类型的特化物(specialization))、版本号、可以在资源树中创建资源的实例的位置、资源实例的属性、激活过程，等等。
资源实例是服务层资源树中与资源类型对应的条目。实例的属性将包含与其创建的目的有关的数据。
资源类型表示资源的目的，诸如用于应用、容器或订阅资源目的。
重定标是将对一个SL实体A(例如，服务器)处的SL资源或属性的请求重定向到所请求的信息所在的另一个实体B(例如，设备)的处理。在这种情况下，实体A处的SL充当请求者与另一个实体B(例如，设备)之间的运输机制。
资源模式是用于指定资源类型的内容的模板。XML模式定义(XML SchemaDefinition，XSD)是可扩展标记语言(XML)格式的资源模式文档的示例。
XSD通过示出可以出现在文档中的元素和属性、子元素的数量和次序、相关联的数据类型以及元素/属性的可能的默认值或固定值来描述XML文档的结构。在oneM2M中，每种资源类型都具有对应的XSD，它示出应当如何构造资源以及资源中包含哪些信息。
M2M/IoT服务层
M2M/IoT服务层(SL)是专门针对为M2M/IoT设备和应用提供增值服务的技术。全球标准机构(诸如oneM2M)正在开发M2M/IoT SL，以解决与将M2M/IoT设备和应用集成到具有Internet/Web、蜂窝、企业和家庭网络的部署中相关联的挑战，如TS-0001oneM2MFunctional Architecture,V-2.10.0中展示的。图1中示出了oneM2M SL架构的示例，其描绘了与公共服务实体(Common Services Entity，CSE)相关联的各种参考点。Mca接口提供对应用实体(AE)的服务层访问，而Mcc和Mcc’参考点允许CSE到CSE的通信。最后，Men接口提供对底层网络技术的访问。
oneM2M架构还提供与非oneM2M技术互通的能力，如图1中所示。这些互通设备也被称为非oneM2M设备节点(NoDN)，并且将它们包括在架构中是oneM2M可以真正声称它是可以与所有垂直市场互操作的水平平台的一个关键原因。
M2M/IoT SL可以为应用和设备提供对面向M2M/IoT的能力集合的访问。这些能力的一些示例包括安全性、计费、数据管理、设备管理、发现、供应(provisioning)和连接性管理。这些能力经由应用编程接口(API)让应用可用，这些API利用M2M/IoT SL支持的消息格式、资源结构和资源表示。
服务层资源管理
在面向资源的服务层架构中，资源管理为应用和设备提供了彼此通信的手段。在oneM2M中，资源具有属性和子资源，以提供实体之间的数据交换。例如，图2示出了示例oneM2M资源，其中椭圆形状表示属性，并且矩形形状(例如，<subscription>)表示子资源。属性指定对应资源的数据模型(例如，memAvailable和memTotal)，并且还可以包括提供附加信息的元数据，诸如资源的mgmtDefinition和description属性之类。资源可以具有已经由标准指定的既定的属性和子资源。照此，标准已经定义了资源和属性是什么、支持的数据类型、特定资源属于资源树中的位置、某些资源或属性的多样性、描述资源类型的模式文档、在资源创建期间执行的XSD验证，等等。总的来说，用于管理对资源的访问的过程和资源的语义被称为资源管理。
与具有既定属性的大多数oneM2M资源相反，存在两种oneM2M资源类型，其中可以定制资源属性：<mgmtObj>和<flexContainer>资源。<mgmtObj>和<flexContainer>资源允许定义对应通用资源的特化物。换句话说，这些资源允许为其它oneM2M资源中找不到的特化功能定义或者<mgmtObj>或者<flexContainer>资源的定制属性。<mgmtObj>资源可以要求到底层技术的标准化映射，如TS-0004Service Layer Core Protocol,V-2.5.0和TS-0006Management Enablement(BBF),V-1.1.4中所讨论的。<flexContainer>资源包含containerDefinition(容器定义)属性，其中向服务层提供到资源模式的链接或统一资源标识符(URI)。但是，当前没有定义任何过程来描述服务层对属性做什么。
与每个资源定义相关联的是XML模式定义(XSD)文档，其描述父资源可以具有的属性和(一个或多个)子资源。此外，XSD文档指定属性和子资源须出现的次序、各自的多样性以及相关联的数据类型。来自XSD的这些“规则”在资源创建时得到验证。图3中示出了[memory(存储器)]特化<mgmtObj>资源的oneM2M XSD文档示例。XSD文档示出[memory]资源具有两个特定于资源的属性：“memAvailable”和“memTotal”，以及对是否可以通告资源的指示。此外，所有属性的次序以及针对每个属性其多样性(无论是强制的还是可选的)以及相关联的数据类型都由XSD文档提供。因此，XSD文档定义了SL管理资源并将其暴露给有兴趣访问该资源的应用所需的信息。
服务层互通
SL互通是使SL架构能够成为用于所有垂直市场的水平平台的关键组成部分。图4中示出了oneM2M内的示例性互通配置。当非oneM2M实体互通时，非oneM2M和oneM2M协议之间的翻译需要互通代理实体(IPE)。翻译的组成部分涉及将oneM2M资源映射到非oneM2M数据模型，反之亦然。IPE通常被实现为使用Mca接口与CSE接口连接的oneM2M AE。除了Mca接口之外，IPE还具有通过其本机(native)协议与互通实体进行通信的非oneM2M接口。
由TS-0001指定三种形式的oneM2M互通。这些包括与非oneM2M数据模型的语义到Mca的完全映射的互通、使用用于编码的非oneM2M数据和命令的经由Mca的透明运输的容器的互通，以及使用经由AE或CSE资源的重定标机制的互通。
非oneM2M数据模型互通的语义的完全映射涉及IPE或AE将互通设备的资源一对一地映射到适当的oneM2M资源和属性中。例如，对于具有温度、湿度和光传感器的设备，IPE或AE将创建三个oneM2M资源，每个资源表示单个传感器。这被视为完全映射。因此，在IPE/AE的设计期间进行手动处理以支持设备进行互通。对于与服务层互通的每个新设备，都需要这个处理。
透明互通涉及将非oneM2M数据模型封装在oneM2M容器资源内并且要求AE对数据进行编码和解码。oneM2M资源内信息的这种隧道化是低效的并且将复杂性推向AE。因此，只有具有底层数据模型和协议的所需知识的AE才可以使用封装在容器资源中的数据。
另一方面，重定标互通完全绕过了服务层提供的大多数功能。在这种形式的互通中，AE或CSE提供oneM2M资源的映射的接口，并且当访问资源时，操作将被重定标到IPE。在这种情况下，不提供对数据模型的内容的深入了解。
除了上面讨论的三种形式的互通之外，还在oneM2M规范TS-0001、TS-0004和TS-0006的设备管理章节中描述了第四种形式的互通。对于设备管理，<mgmtObj>资源是标准化的oneM2M资源，其表示底层设备管理(DM)技术的数据模型，并且AE访问这些<mgmtObj>资源以管理设备。
OMA LWM2M
轻量级M2M(LWM2M)协议基于客户端-服务器架构，该架构以更适用于受约束的设备的简单且平坦的资源结构为特征。有关LWM2M协议的更多信息可以在开放移动联盟(OMA)Lightweight Machine to Machine Technical Specification版本1.0中找到。资源树被定义为LWM2M对象，资源树下的资源以具有较少层级的扁平结构组织。LWM2M中对象和资源的定义分别映射到oneM2M架构中的资源和属性的定义。图5中示出了示例性LWM2M架构。
除了支持设备管理之外，LWM2M协议还支持由受约束的设备提供的服务启用。由于受约束的设备主要为特定应用提供数据测量，因此信息报告是该协议中指定的主要服务启用。照此，对象的设计侧重于提供将支持设备管理和信息报告的资源。
使用现有服务层标准的示例部署场景
图6示出了示例服务层部署场景，其中服务层(例如，oneM2M服务器)支持LWM2M互通。在部署时，服务层支持OMA LWM2M技术规范、TS-0005Management Enablement(OMA)，V-1.4.1和TS-0001中指定的LWM2M对象。如图6中所示，Customer1(顾客1)最初部署支持OMALWM2M技术规范中定义的LWM2M对象的设备1，并且App1(应用1)用于管理设备1。一段时间后，设备1更新了一些扩展的LWM2M对象，诸如未在TS-0001或TS-0005中定义的LockWipe和连接性管理对象之类。由于新的LWM2M对象最初未在TS-0001和TS-0005中指定，因此服务层不支持它们。此外，顾客1部署包含一些特定于供应商的LWM2M对象的设备2，这些特定于供应商的LWM2M对象未在TS-0005或OMA LWM2M技术规范中定义。服务层再次无法支持这些新对象。
在另一个实例中，顾客2想要整合其操作，因为它管理来自两种不同技术(例如，oneM2M和开放的互联网协会(Open Internet Consortium，OIC))的设备。顾客2已经使用App2来管理其服务层设备，并希望将其OIC设备迁移到服务层。以这种方式，顾客2将只能使用App2来管理其所有设备。与上述LWM2M场景类似，顾客2无法使用服务层管理设备3，因为这个OIC设备不被支持。
上面描述的场景说明了通用互通由诸如oneM2M之类的服务层标准定义的方式中的缺口(gap)。目前，oneM2M以抽象的方式定义了用于互通技术的数据模型的资源映射，诸如例如LWM2M(如TS-0014TWM2M Interworking，V-0.13.0中所描述的)、AllJoyn(如TS-0021oneM2M and AllJoyn Interworking，V-0.3.0中所描述的)和OIC(如TS-0024OICInterworking，V-0.4.0中所描述的)。这些映射不完整、令人困惑或完全缺乏。例如，在LWM2M的情况下，数据模型之间不存在一对一的映射。此外，LWM2M固件更新对象的并没有使其所有资源映射到oneM2M[firmware(固件)]属性。如图7中所示，LWM2M设备对象映射到四个不同的oneM2M<mgmtObj>。最后，LWM2M连接性监视和连接性状态对象甚至没有映射到oneM2M资源。
另外两个oneM2M互通方案完全从服务层隐藏了互通设备的数据模型。在这些情况下，互通资源被封装在“内容共享资源”中，其可以表示为CSE、AE或容器资源。在透明互通中，非oneM2M数据模型被封装在容器资源内，这要求应用对数据进行编码和解码。由于编码和解码要求，oneM2M应用需要理解oneM2M协议以及互通技术的协议。类似地，重定标互通完全绕过了服务层提供的大多数功能。在这种形式的互通中，通常创建CSE或AE资源以表示互通实体，并且将对资源的请求重定标到IPE。通过从服务层隐藏互通数据模型，这两种方案限制了与感兴趣的域内的应用的互通。
在非oneM2M数据模型互通的语义的完全映射中，提供了互通数据模型到oneM2M资源的一对一映射。但是，完成这种完全映射的处理本质上是手动的并且在IPE/AE的设计期间执行。当存在许多不同类型的设备时，这种方法不能很好地扩展。每个设备都要求自己的映射和对IPE/AE设计的更新。
最后，图6中所示的示例突出了缺乏对诸如oneM2M之类的水平服务层平台的重要特征的支持-高效且动态地支持特定于供应商的数据模型的能力。oneM2M标准已经提供了可以定制的资源，例如<mgmtObj>和<flexContainer>资源，以支持互通。但是，oneM2M目前缺乏利用动态定制资源属性的能力的过程。这些特定于供应商的资源对于来自相同垂直市场的供应商而言至关重要，以区分其产品供给并展示其平台的增值。当扩展到包括来自不同垂直市场的供应商时，这种动态互通机制的好处被放大。
服务层架构内的通用互通
为了使服务层互通普遍且高效地工作，互通设备的数据模型应当暴露给所有应用，并且应当存在动态机制来添加或更新互通设备的数据模型的映射资源定义。这些能力将使服务层架构能够将各种垂直市场带到单个水平平台中。此外，可以将新资源类型添加到服务层以用于可扩展性。本文公开了用于支持服务层互通和资源可扩展性的轻量级动态机制。
例如，图8示出了在服务层架构内启用通用互通的示例性端到端过程的高级别概述。图8是图4中所示的互通架构的一个实现。如本文所讨论的，可以将第三方数据模型的一对一映射作为互通的一部分提供给服务层资源。另外，服务层可以被配置为支持新资源类型或现有资源类型的组合。但是，新资源类型仅限于服务层支持的操作。如果新资源类型要求新功能或服务，那么须启用使那些功能或服务可用的替代手段，以支持新资源类型。
根据本文公开的一个方面，类似于如何在标准规范中定义资源类型，资源定义文档描述资源类型。例如，在TS-0001中描述了oneM2M<AE>，其中列出了AE的属性和子资源、它具有哪些公共属性、它在资源树中的位置、其属性的多样性以及具有对应数据类型的子资源，等等。此外，在TS-0004中提供了协议绑定，其中可以指定以下内容：数据类型和XSD或模式文件、使用的短名称、原始属性的可选性、访问资源的过程，等等。所有这种信息都包含在资源定义文档中，该文档还包含有关服务层应当如何激活资源定义以使其可供使用的附加指示。
根据本文公开的另一方面，数据模型映射文档可以用于提供第三方资源到服务层资源属性的一对一映射。因此，它类似于描述特定于资源的属性的模式文件的部分。该文档提供了服务层资源属性到第三方资源的映射，诸如在TS-0005中为LWM2M提供的。这种信息在协议翻译期间使用。此外，数据模型映射文档包括用于每个资源属性的重定标指示符，以指示服务层何时将检索请求重定标以最小化消息传送流量。
如图8的示例中所示，首先为IPE供应用于互通设备的新资源定义。然后将这种资源定义向服务层注册，服务层将新资源的管理添加到服务层的操作。接下来，将数据模型映射供应给IPE，其中，互通设备的数据模型被映射到SL资源属性。这个数据模型映射也向服务层注册，以提供重定标指示符，用于优化到互通资源的消息传送。然后将互通设备向IPE注册或供应，IPE进而将该设备向服务层注册。例如，LWM2M设备向LWM2M服务器注册，该服务器是IPE的一部分，然后IPE将该设备向服务层注册。
作为初始步骤，虽然未在图8中示出，但是IPE和服务层被供应为安全地彼此通信，例如，通过包括SL注册和访问控制供应。图8示出了IPE向服务层注册资源定义和数据模型映射文档两者。类似地，管理SL应用或服务器管理员也可以将这些文档向服务层而不是IPE。术语IPE、管理SL应用和服务层管理员可以互换使用。
一旦完成了所有注册过程(例如，在完成步骤1至5之后)，应用就可以使用服务层的资源发现过程来找到新的互通设备资源。然后，应用发出针对互通资源的请求，并且服务层评估互通重定标指示符的标准，以确定是否发起通用的互通过程。如果发起，那么服务层将应用的请求重定标到IPE，IPE执行从SL协议到本机互通设备的协议的通用互通映射。要注意的是，如果被一些SL请求的数据本质上是静态的，那么所述请求可以不被重定标到IPE。但是，至少要求一个重定标的请求来检索静态数据。从互通设备返回的响应从IPE中继到服务层，并且最后到应用。服务层可以取决于重定标指示符来高速缓存响应。
SL资源定义文档注册过程
根据本文公开的第一方面，在启用服务层处的互通之前，定义资源定义以提供从互通设备资源到SL资源和属性的一对一映射。资源定义本质上反映了在标准化期间执行的相同工作，其中定义资源类型、给予特化资源类型的名称(如果存在的话)、资源类型的属性和子资源、描述资源以供在对资源创建的验证中使用的模式文档、以及管理资源的其它信息和过程。资源定义所要求的信息在文档中捕获，然后使用本文中的思想将该文档提供给IPE、管理应用或服务器管理员以向服务层注册。
一对一映射由两个步骤组成：识别访问和/或管理设备所要求的本机数据模型以及将设备的本机数据模型映射到服务层资源和属性。映射的结果将生成SL资源定义文档和数据模型映射文档两者。资源定义文档被提供给SL以定义新资源或资源类型，即，定义新的定制资源或定制资源类型，而数据模型映射文档被提供给SL以进行互通。在SL内，数据模型映射文档提供重定标指示符，以告知服务层何时应当重定标对资源的请求。IPE使用数据模型映射文档以用于协议翻译和重定标两者。协议翻译可以涉及创建互通设备理解的新消息。重定标可以涉及IPE与互通设备通信以获得返回服务层的响应。
一旦资源定义和数据模型映射完成，就将文档供应给IPE以发起向服务层的对应注册。IPE将首先向服务层注册资源定义。这种注册与当前的SL注册不同，因为它是注册新资源定义而不是请求SL创建SL资源的新实例。因此，注册请求的目标URI是针对虚拟资源的，其向SL表示正在注册资源定义。
以虚拟资源而不是正常SL资源为目标的目的是通知服务层注册操作在正常操作模式之外并且在资源树中没有创建资源实例。但是，也可以在资源树中创建新的服务层资源，以托管服务层支持的所有资源定义。在这种情况下，注册请求的目标URI将以该新SL资源为目标。例如，可以在SL资源树中创建新的“resourceDefinitions(资源定义)”资源以存储所有资源定义。目标URI可以是例如“/resourceDefinitions”或“/<SL_name>/resourceDefinitions”的形式。在这种情况下，资源定义须包含使用虚拟资源方法的资源定义将不具有的两个额外属性：激活和停用。将利用这些属性来使得能够使用如下所述的资源定义。
服务层可以以多种方式管理资源定义注册。服务层可以将资源定义保存在内部储存库中，其中该资源定义可以用于验证针对资源的未来请求。这可以被实现为在服务层服务器内的某个位置保存文件。可替代地，服务层可以在资源树中创建资源，以通过正常的资源发现将资源定义暴露给服务层的注册者。这是当前服务层资源被处理的方式。此外，这两种替代方案可以组合在一起，以提供更透明、灵活和功能性的操作。
图9示出了IPE对服务层做出的示例性资源定义注册过程，如下面所讨论的。
在步骤1中，在IPE被供应互通设备的资源定义文档之后，它将该文档向服务层注册。在注册请求中，IPE以虚拟资源为目标，以指示注册是针对资源定义的注册。虚拟资源的示例URI可以采用以下形式：/<SL_name>/resourceDefinitions。该请求中包括用于交互设备的资源定义文档。该文档将包括服务层管理资源和暴露资源以进行资源发现所需的信息。表1示出了构成资源定义文档的不同组成部分。提供的信息将使服务层能够从资源定义文档中提取oneM2M XSD文档，以在激活后使用。可替代地，可以在注册请求中提供URI，服务层可以从所述URI中检索资源定义文档。
作为将资源定义显式地向服务层注册的替代方案，可以通过创建具有向模式文档提供URI的属性的资源来隐式地触发资源定义注册。在这种情况下，服务层将在步骤2中处理既注册模式文档又激活定义的请求。这个替代方案仅限于包含用于指定模式文件位置的属性的现有服务层资源，并且不能用于在服务层中创建新资源类型。
在步骤2中，服务层评估由IPE提供的资源定义，以对其包含表1中指定的所有要求的组成部分以及每个组成部分内的所有要求的信息进行核实。要注意的是，信息要求是特定于实现的。这对于所提供的激活标准的内容尤其重要。在步骤1中提供URI的情况下，服务层在评估资源定义之前先下载文档。在确定资源定义有效且可接受之后，服务层将文档添加到其资源定义储存库以供在激活资源定义中使用。
当通过创建包含到模式文档的URI的服务层资源来触发这个过程时，服务层执行附加处理以激活检索到的模式文档。附加处理取决于实现并且可以包括以下项：验证模式文档是被良好格式化的、将模式文档保存到服务层的本地储存库、使模式文档可用于资源发现，等等。
在步骤3中，服务层向IPE发送适当的响应。如果创建成功，那么服务层可以提供用于检索资源定义的URI。该URI可以由来自步骤1的虚拟URI前缀、由服务层为资源定义提供的资源名称或其它标识符以及资源定义的版本构成。如果通过创建包含到模式文档的URI的资源来触发该过程，那么服务层将返回正常创建响应以及用于访问模式文档的URI。
表1：资源定义文档的组成部分
图9中指定的过程示出了IPE进行资源定义注册请求。可替代地，这个请求可以由管理服务层应用进行。这种管理应用可以用于管理服务层的操作并且可以具有用于更改服务器的操作的特殊访问特权。应用可以由服务提供者或服务层所有者控制。第三种替代方案是让服务层管理员执行资源定义注册。这个功能可以内置到服务层操作中，并且可以通过web接口、命令行接口或通过某种其它机制来实现。
要注意的是，图9中指定的过程可以用于定义在服务层部署时不存在的新资源类型。例如，基于资源定义的版本1部署服务层。在部署之后，在版本2中创建新的资源类型。使用本节中概述的过程，可以更新服务层以支持新的资源类型。此外，该过程还允许支持相同资源类型的各种版本。这使得服务层能够使用相同资源的不同版本以传统设备和新设备操作。
SL资源定义管理过程
一旦已经注册了资源定义，服务层就提供通过用于发现、检索、更新、移除、激活和停用的过程来管理定义的能力。要注意的是，资源定义的管理确定了如何执行访问定义的过程。如果服务层将资源定义暴露为资源树中的资源，那么将使用正常的SL请求(发现、检索、更新和删除)来访问资源定义。但是，如果服务层将资源定义保存到文件并将资源定义存储在内部储存库中，那么定义以下过程来访问资源定义。
资源定义的管理涉及两个储存库集合：一个用于资源定义文档，并且另一个用于模式文档。服务层使用资源定义文档在下面描述的激活过程期间生成对应的模式文档。因此，文档被存储在分开的储存库中。资源定义储存库只能由通过严格授权处理被准许访问的服务层管理员、管理应用或IPE访问。这种储存库可以用于指示服务层支持的所有资源的资源定义，并且在正常服务层操作期间不被访问。模式文档储存库可以仅限于服务层本身及其管理员，因为它在正常操作(诸如验证资源的创建请求)期间使用。可以采用这种限制来防止诸如IPE之类的外部实体可能地干扰服务层的操作。因此，IPE和管理应用只能对模式储存库进行读访问。
这些管理过程允许诸如服务器管理员之类的授权实体与服务层交互，以便不仅创建新资源类型而且还基于现有资源类型定义新资源类型。管理员可以使用这个接口发现并检索现有资源类型，以基于检索到的资源类型创建新资源类型。服务层还可以使用这个接口与其它服务层交换资源定义文档，以更新其操作。此外，如果通过标准化对资源类型进行了改变，那么可以创建相同资源类型的新版本。最后，获得授权的供应商可以定义自己的特定资源，并使用该接口注册其资源，以区分其产品供给。
资源定义发现
类似于现有的SL资源发现，执行资源定义发现以找到服务层支持哪些资源定义。用于资源定义注册的相同目标URI可以用于资源定义发现。可以使用服务层资源发现过程的简化版本来发现这些资源定义。现有SL发现与这种简化发现之间的区别在于目标URI是虚拟资源并且过滤标准被发现标准代替。由于这种发现请求主要关注资源定义，因此无需使用更复杂的过滤标准。诸如在何时之前创建、自何时修改、尺寸高于、限制、语义过滤(semanticsFilter)等的属性可能不适用于资源定义发现请求。图10示出了示例性简化发现过程，如下面所讨论的。
在步骤1中，应用或IPE执行以SL资源(诸如在注册资源定义时使用的URI)为目标的检索操作。该请求可以包括发现标准，以缩窄对具体资源定义的搜索范围。发现标准可以由键-值对的列表组成。表2中示出了标准的一些示例。
在步骤2中，服务层接收请求、识别发现标准、并搜索其内部储存库以定位期望的资源定义。如果找到多于一个资源定义，那么服务层可以编译资源定义名称的列表。
在步骤3中，服务层返回将发现标准与适当的响应代码匹配的资源定义名称和相关联的版本的列表。要注意的是，资源定义名称可以包括版本号以及相同资源定义的多个版本。可选地，返回的列表可以包括资源定义文档和/或模式文档的URI，IPE可以通过所述URI检索定义或模式文档的内容。
表2：资源定义发现标准的示例
发现标准 描述
资源类型定义名称 已注册的资源定义的名称，其可以包括对应的版本
资源类型 服务层中的资源的类型
定义版本 资源定义版本
资源树位置 可以创建资源的资源树URI
定义已激活 资源定义的状态(已激活/已停用)
包含属性 资源支持的属性名称
包含子资源 资源支持的子资源
可执行属性 包含可执行的属性的任何资源
资源定义检索
一旦发现了资源定义的名称或URI，应用或IPE就可以检索期望定义的内容。该请求类似于资源的SL检索请求，其差异在于请求的URI，即，虚拟URI与资源定义名称的串联，以及服务层从其内部储库存中获取资源定义的事实。对检索请求的响应将包括资源定义以及该定义是否已激活的指示符。如果由于创建为模式文档提供URI的资源而自动触发资源定义注册，那么响应于创建请求或经由上述资源定义发现过程提供访问模式文档的该URI。
资源定义更新
当资源定义由内部储存库管理时，由于其在文件中携带，因此更新定义的提供有限。如果更新涉及改变资源定义文档中已存在的值，那么允许部分更新。更新请求提供需要改变的(一个或多个)值。但是，如果更新涉及向该文件添加或删除内容，那么应用或IPE将需要使用由图9指定的Create(创建)请求更新整个定义文件。由于不要求服务层解析文件、定位在哪里更新文件、以及将新内容添加到文件，因此这导致对定义文件的管理的简化。
资源定义移除
资源定义可以在被激活之前或者在被停用之后被移除。除了是删除资源定义文件而不是资源树中的资源实例之外，这个过程类似于资源的SL删除。要注意的是，如果资源定义被激活，那么无法从储存库中移除它。这防止在基于定义的资源仍在使用时删除该资源定义。如果资源定义已激活但没有资源在使用中，那么由服务层决定是否允许删除该资源定义文件。
资源定义激活
一旦资源定义已经注册，就应当激活资源定义以供服务层使用。在资源定义可以被服务层使用之前，激活处理可以用于触发各种检查和过程。可以被触发的内容的示例包括：1)服务提供者或服务层所有者进行的用于确保请求者可以激活资源定义的授权检查，2)从资源定义文档中提取如图3中描述的模式文档，3)验证提取出的模式文档是被良好格式化的，4)以及将模式文档保存到服务层模式储存库并集成到包括对资源发现机制的更新的服务层操作中。对于这个激活处理，还有其它潜在的用途，并且上面提到的用途可以组合在一起，作为激活处理的一部分。一旦激活完成，服务层就可以使用提取出的模式文档在其自己的资源树中创建资源。
激活处理是重要的，因为它改变服务层的行为，例如，通过验证新资源类型的创建请求或对现有资源类型的修改以及对模式和数据库储存库的改变(用于创建资源实例)。此外，与标准访问控制检查相比，授权检查可能更复杂(invovled)，因为如果未正确执行，那么激活可能造成服务层中的不想要的行为。图11示出了从激活处理产生的一些可能动作，如下面所讨论的。
在步骤1中，应用或IPE发送以虚拟资源的URI为目标、具有其版本的资源定义名称、以及在该URI的末尾处的“/activate(激活)”的Create请求。可替代地，如果在SL资源树中创建了资源定义，那么可以把“activate”属性作为目标。该请求触发服务层内的激活过程。资源定义文件提供用于激活的标准。然后，服务层读取这些标准以确定要采取的操作。其中一些动作可以取决于事先执行的其它动作。例如，应当在验证模式文档被良好格式化之前执行从资源定义文档中提取模式文档。因此，在接受资源定义注册之前，资源定义文档的激活标准部分的内容应当具有严格的指导和验证。
在步骤2中，服务层可以可选地向授权服务器发送请求，以检查应用或IPE是否可以激活资源定义。取决于服务层的尺寸和复杂程度，可以将这个请求发送到第三方或服务提供者的授权服务器。可替代地，可以基于某个策略或配置参数在服务层内对其进行评估。也可以在通过创建提供到模式文档的URI的资源实例来触发激活过程时执行该授权检查，并且可以添加新的授权参数以指定所需的授权检查。
在步骤3中，授权服务器以适当的消息进行响应。如果响应指示应用或IPE没有授权，那么服务层将停止激活处理并在步骤7中相应地做出响应。
在步骤4中，如果应用或IPE被授权，那么服务层将资源定义集成到服务器的操作中。这可能需要从资源定义文档中提取模式文件，并核实生成的文件是被良好格式化的。可替代地，可以更新有效资源定义文件的数据库以包括新资源定义。此外，可以进行更新以暴露新资源类型以用于发现目的。
在步骤5中，一旦服务层已经验证了模式文档被良好格式化，它就可以将该文档保存到其内部储存库以供将来使用。例如，服务层可以核实模式文档符合XML 1.0规范的既定语法规则，该规范指定为了被良好格式化，XML文档必须满足某些物理和逻辑结构。
在步骤6中，返回关于将模式文档集成到服务层操作中的状态。
在步骤7中，服务层返回对激活请求的适当响应。如果任何激活处理/过程失败，那么响应可以指示哪些处理/过程未能帮助应用/IPE调试(debug)失败的(一个或多个)部分。
资源定义停用
资源定义停用比激活更简单，因为该处理仅要求服务层确保资源树中不存在使用作为目标的定义的资源。这是为了确保，如果服务层需要验证针对资源定义的任何未来请求，那么该定义可用。如果服务层资源树中没有资源使用该定义，那么SL可以停用该资源定义。图12示出了由停用处理产生的一些可能的动作，如下面所讨论的。
在步骤1中，应用或IPE确定不再需要资源定义，因为那个类型的SL中不存在任何资源实例。将请求发送到服务层，所述请求以资源定义及其版本为目标并在目标URI的末尾附加“/deactivate(停用)”。可替代地，如果在SL资源树中创建了资源定义，那么可以以“deactivate”属性为目标。
在步骤2中，服务层检查其自己的资源树以确保没有现有资源实例正在使用该资源定义。如果存在使用该资源定义的未决的资源实例，那么拒绝停用请求。如果没有资源实例在使用中，那么服务层删除该资源定义。
在步骤3中，服务层可以从其内部储存库中移除模式文档，并移除资源类型以防被发现。
在步骤4中，针对模式文档的移除返回状态。
在步骤5中，服务层返回用于停用请求的适当响应代码。
SL数据模型映射文档注册过程
在激活资源定义之后，IPE、管理应用或服务器管理员然后可以将数据模型映射文档向服务层注册。数据模型映射文档提供重定标指示符，所述重定标指示符描述服务层应当如何将请求重定标到互通的服务层资源。数据模型映射还用于协议翻译。首先激活资源定义是重要的，使得服务层可以对照根据资源定义的生成的模式文件来处理这个注册请求中提供的数据模型映射。数据模型映射文档应当包含生成的模式文档中提供的特定于资源的属性的完全列表。此外，该文档将包含针对每个特定于SL资源的属性的互通数据模型的相关联URI。可以在用于LWM2M的TS-0005中找到数据模型映射的一些示例(没有重定标指示符)。数据模型映射文档提供特定于服务层资源的属性与互通数据模型资源URI之间的一对一对应关系。
IPE被供应有数据模型映射文档，该文档包含与资源定义文档中的特定于资源的属性的列表相同的特定于资源的属性的列表。在将新参数添加到数据模型映射文档时，仅保留特定于资源的属性的名称。其中一些新参数包括具有相关联数据类型的互通数据模型的资源URI以及重定标指示符。可以包括其它参数以考虑IPE的附加特征。在协议翻译期间使用资源URI以从服务层资源属性映射到第三方资源，反之亦然，而重定标指示符参数将在下面更详细地描述。
一旦IPE被供应有数据映射文档，它就可以进一步处理该文档以生成用于向服务层注册的副本。这可以涉及基于IPE的能力改变如下所述的重定标指示符(或其它参数)。在那种情况下，IPE使用的数据模型映射文档将不同于向服务层注册的文档。
要注意的是，资源定义和数据模型映射文档的内容可以组合在一起成为一个文档。在这种场景中，上述过程仍然适用，但现在将应用于该复合文档，其既包含资源定义又包含数据模型映射信息。因此，用于资源定义注册和管理的过程与用于数据模型映射注册和管理的过程被组合。资源定义文档也将包含数据模型映射信息，并且服务层可以将新信息保存在模式文档中或将它们分离为两个文档。数据模型映射信息可以是可选的，以支持新服务层资源类型或修改后的资源类型资源定义被注册并且不需要互通的情况。
图13示出了数据模型映射文档向服务层的示例性注册过程，如下面所讨论的。
在步骤1中，IPE发送针对虚拟资源“/resourceMappings”的Create请求以指示注册是针对资源映射的注册。完整的资源映射文档被添加到消息的有效载荷。
在步骤2中，服务层核实由请求提供的映射文档中的资源属性名称和相关联数据类型与对应模式文档中的资源属性名称和相关联数据类型匹配。这种检查确保将所有特定于资源的属性映射到某个互通的数据模型资源。还要注意的是，映射管理是在幕后完成的，并且资源树中不创建服务层资源。相反，当重定标未来的互通请求时，映射被保存到文件以供服务层使用。
在步骤3中，如果创建成功，那么服务层返回具有资源映射文档的位置和相关联版本号的适当响应。
除了目标URI的改变之外，用于数据模型映射的管理过程遵循如上所述的资源定义的管理过程。代替使用“/resourceDefinitions”，目标URI将是“/resourceMappings”。用于数据模型映射的发现标准是用于资源定义的发现标准的子集。最后，数据模型映射不需要被激活或停用，因为它们与资源定义一起工作。如果组合资源定义文档和数据模型映射文档，那么对于复合文档，只需要一个管理过程集合。
互通重定标指示符
除了提供互通资源的URI之外，数据模型映射还可以包含用于每个映射资源的重定标指示符。这个指示符可以基于针对每个映射提供的重定标指示符向IPE和服务层二者提供关于何时重定标检索请求的指导。对于创建、更新和删除请求，它们始终被重定标，以确保SL资源与互通设备上的资源之间的同步。表3示出了根据一个实施例的重定标指示符的示例。在其它实施例中，可以支持更多或更少的重定标指示符。使用这些重定标指示符可以帮助使服务层免于对本质为静态或半静态的数据执行不必要的检索请求。
表3：互通重定标指示符
IPE可以使用表3中提供的重定标指示符来管理服务层上托管的互通资源。向服务层注册的映射文档可以只包含两个指示符：一次重定标和总是重定标。对于重定标指示符2和3，IPE的能力将确定指示符是否从2或3独立地变为或者1或者0。如果IPE与管理互通设备的第三方服务器集成，那么IPE可以知道具有重定标指示符2的属性何时被改变并且对SL资源进行对应的更新。同样，如果IPE支持定期刷新，那么它可以保持在SL资源中更新的具有重定标指示符3的属性。在这两种情况下，IPE都会动态更新服务层中的资源属性以确保新鲜度，并将那些属性在数据模型映射文档中配置为一次重定标。如果IPE仅支持两种能力之一，那么只有与那个能力相关联的属性才会被配置为一次重定标。其重定标指示符要求IPE不支持的功能的属性将被配置为总是重定标。
重定标指示符被提供为应用于特定资源类型的数据模型映射文档的一部分。这将对于使用相同资源类型的所有设备确保一致的重定标指示符。但是，可以基于每个资源实例扩展重定标指示符以便以更通用的方式使用。这在资源实例级别提供了更细粒度的重定标控制。每个资源实例和对应的互通资源可以具有其自己的重定标指示符，而与资源类型无关。例如，两个传感器可以使用相同的资源类型来提供温度读数，但是针对不同的应用。位于家中的一个传感器要求每30分钟的温度读数。第二个温度传感器位于化学处理实验室，每分钟都要求读数。当创建相关联的温度资源实例时，每个实例都将被配置为“定期重定标”，但是具有指定的不同周期。
虽然提出了重定标指示符用于互通，但是这些概念也可以应用于现有的服务层重定标。例如，可以将新的重定标指示符属性(如表3中所述的那些)添加到已通告的资源中，以指示服务层何时重定标。
服务层通用互通过程
根据本文公开的第三方面，在资源定义和资源映射文档都被注册之后，SL应用可以在互通资源被创建之后发出对互通资源的请求。SL应用可以像其它SL资源一样使用资源发现来查找互通资源。在发现之后，应用可以对互通资源执行RESTful操作，并像其它SL资源一样获得响应。当针对互通资源做出请求时，可以在服务层与IPE之间触发通用的SL互通过程。在图14的示例中概述了下面进一步讨论的这个过程。
参考图14，在步骤0中，互通系统被配置并可操作。这包括资源定义和数据模型映射注册、IPE和应用的SL注册、向IPE注册IW设备、IPE在服务层上创建互通资源以及相关联的订阅、以及是不同的行动者之间能够进行通信所需的所有其它配置。
在步骤1中，应用执行服务层资源发现并找到它正在寻找的互通资源。
在步骤2中，作出针对服务层中的互通资源的请求。
在步骤3中，服务层评估作为目标的互通资源的重定标指示符，并使用数据模型映射文档确定是否将请求重定标到IPE。对于一次重定标属性的检索请求，在步骤9中SL返回在根据先前重定标的请求而存在属性的值的情况下，可能已被高速缓存的该属性的值。如果未找到高速缓存的值，那么进行重定的标请求以从互通资设备获取值。对于所有其它请求，服务层重定标请求并生成通知消息以发送到IPE。
在步骤4中，针对所请求的资源向IPE发送通知。
在步骤5中，IPE从通知消息中提取作为目标的资源，并使用数据模型映射文档将服务层资源翻译成互通资源。此外，IPE执行协议翻译以创建针对从数据模型映射文档获得的互通资源URI的新请求消息。
在步骤6中，IPE以符合设备技术的格式(例如，LWM2M、OIC等)向互通设备发送消息，并且该设备向IPE返回适当的响应。如果IPE未与管理设备的第三方服务器集成，那么这个步骤可以是多步骤处理。IPE和第三方服务器之间以及第三方服务器和设备之间将进行消息交换。在IPE接收到响应之后，它将执行反向协议翻译和数据模型映射，以创建对服务层的新的响应消息。
在步骤7中，IPE向服务层发送适当的响应。
在步骤8中，服务层基于重定标指示符确定是否高速缓存每个互通资源属性的对应值。如果指示符被设置为一次重定标，那么服务层将保存在响应中的信息以供将来使用。如果另一个应用或甚至同一个应用对服务层内保存的信息执行后续检索，那么不需要重定标，因为已经获取了该信息并且服务层可以返回保存的信息。
在步骤9中，将适当的响应返回到发出请求的应用。
示例oneM2M实施例
图15示出了其中创建新的oneM2M公共服务功能(CSF)并且更新现有CSF的示例性实施例。新的资源管理CSF可以处理资源定义和资源映射注册两者，并且可以使用新的互通CSF来评估互通资源的重定标标准。可替代地，可以更新数据管理和储存库以允许创建新资源类型来代替资源管理CSF。
除了CSF改变之外，还可以将新的oneM2M资源和/或资源属性添加到服务层。表4示出了可以添加到服务层的示例性新“资源”。
表4：新的oneM2M资源的示例
示例oneM2M资源定义文档
图16中示出了可以在oneM2M内使用的资源定义文档的示例。这个文档示出了资源定义文档的五个主要部分：资源定义信息、服务层资源属性、特定于资源的属性、互通资源的子资源、以及激活标准。要注意的是，在特定于资源的属性中，dmServerInfoAnnc元素标签已被压缩为一行，以适合图中的整个文档。
具体而言，图16中所示的文档描绘了针对LWM2M服务器信息对象的示例资源定义。在顶部，提供了各种资源信息以通过名称和类型来识别资源并提供关于资源的元数据，诸如版本号、短名称、资源标签、以及资源可以存在于资源树中的何处之类。资源属性(Resource Attributes)、特定于资源的属性(Resource Specific Attributes)和子资源(Child Resources)部分包括进入oneM2MXSD文件的内容。最后，激活标准(ActivationCriteria)部分向服务层提供关于如何激活定义文档以启用资源的使用的指示。
虽然资源定义文档被用作互通支持的一部分，但是它也可以在正常服务层操作中以基于现有类型来注册新资源类型或资源。例如，使用上面给出的思想，可以升级用某个资源类型的版本1.0部署的服务层，以支持将来使用相同资源的版本1.1。资源也可以是不需要数据模型映射文档的仅服务层资源。这就是为什么资源定义文档和数据模型映射文档分开注册以及只需要激活资源定义的原因。除了支持相同资源的不同版本之外，服务层还可以支持由服务层所有者创建的定制资源，如在家庭自动化中本地化服务层部署的情况下。
示例oneM2M数据模型映射文档
通过提取资源定义文档的特定于资源(Resource Specific Attributes)的属性部分中的信息、保持名称参数并为每个特定于资源的属性添加targetURI和retargetLevel参数来生成数据模型映射文档。图17示出了XML格式的、用于LWM2M服务器信息对象的数据模型映射文档的示例。也可以使用其它格式，诸如纯文本、JSON、CoRE Link格式等。要注意的是，图16中的资源定义文档的特定于资源的属性部分和图17中的数据模型映射文档是相似的(例如，它们都包含相同的特定于资源的属性)。
在协议翻译期间，由IPE使用图17中所示的示例数据模型映射文档。这个文档使用由表3指定的所有重定标指示符。如前所述，向服务层注册的数据模型映射文档将仅包含两个指示符：一次重定标和总是重定标。因此，IPE生成新的数据模型映射文档，以供向服务层注册时使用。这个新文件将基于IPE的能力将重定标指示符2和3改变为或者0或者1。在这种情况下的示例将IPE和第三方服务器作为分开的实体，IPE仅支持定期重定标。
图18示出了IPE向服务层注册的示例数据模型映射文档。由于IPE支持定期重定标，因此lifetime(寿命)属性的重定标级别设置为0(一次重定标)。IPE支持这个能力并将动态更新这个资源属性，以便服务层将总是具有最新的值。对于图17中的重定标指示符为2(在改变时重定标)的其它属性，IPE不支持这个特征。因此，那些值被设置为1(总是重定标)。
示例调用流程
如上面所讨论的，通过为来自不同系统和来自不同垂直市场或甚至同一垂直市场的供应商的互通资源提供支持动态资源管理的灵活性，可以向服务层部署添加巨大的价值。此外，可以为服务层服务提供者或所有者定制现有的服务层资源(例如，<mgmtObj>和<flexContainer>)。在下面讨论的oneM2M<mgmtObj>和<flexContainer>互通示例、多供应商互通示例和LWM2M互通示例中展示了许多这些优点。
oneM2M<mgmtObj>XSD激活示例
oneM2M的<mgmtObj>资源提供通过objectAttribute属性创建用于设备管理(例如，LWM2M)的特化资源的能力。这是个可定制的属性，它可以用于直接映射到底层设备管理技术的数据模型资源。mgmtDefinition和objectIDs属性定义<mgmtObj>资源被针对什么样的特化对象类型而定制。目前，这些属性是在标准化处理中定义的，因此不提供动态定义新特化物的灵活性。
使用上面给出的思想，可以更新当前的oneM2M<mgmtObj>资源以动态地支持新的特化物资源。表5示出了用于<mgmtObj>资源的特定于资源的属性以及对objectIDs属性的建议改变，以便支持动态定义新的特化物资源。这种改变扩展了<mgmtObj>资源的定义，以修改objectIDs属性，以便为与LWM2M对象定义对应的特化<mgmtObj>资源的XSD提供URN或URI。可以在创建特化<mgmtObj>资源期间指定objectIDs。在objectIDs属性中指定URI的选项允许CSE支持在CSE的初始部署时不可用的新LWM2M对象。在特定于供应商的LWM2M对象的情况下，尤其如此。URI将指向可以找到并检索新的特化<mgmtObj>资源的XSD以供CSE使用的位置。
表5：<mgmtObj>特定于资源的属性
/>
图19示出了oneM2M托管CSE执行以使用objectIDs属性创建新的特化<mgmtObj>资源的更新后的过程。
在步骤001中，对于特化<mgmtObj>资源的CREATE操作，发起方在请求消息中发送强制参数并且可以发送可选参数。特化<mgmtObj>资源包含底层LWM2M对象的完全映射并包括用于objectIDs属性中新特化资源的XSD的URI。
在步骤002中，接收方：
检查发起方是否具有执行请求的适当特权；以及
核实由Content参数中的resourceName属性建议的用于所创建资源的名称在作为目标的资源的子资源当中并未已经存在。
在步骤003中，接收方检查是否在CSEBase的supportedResourceType属性中找到特化<mgmtObj>资源。如果在supportedResourceType属性中找到特化<mgmtObj>资源，那么请转到步骤8；否则，请转到步骤4。
在步骤004中，接收方提取objectIDs属性的内容并从XSD储存库检索XSD。
在步骤005中，XSD储存库返回用于特化<mgmtObj>资源的XSD。
在步骤006中，接收方检查接收到的XSD是被良好格式化的，如果是，那么将XSD保存到接收方的本地XSD储存库。
在步骤007中，接收方用特化<mgmtObj>的名称更新supportedResourceType属性。
在步骤008中，接收方完成处理CREATE请求。这可以包括：
将Resource-ID(资源ID)指派给要创建的资源；
为资源的强制RO(只读)模式属性指派值，并为资源类型定义允许且如果不是由发起方本身提供的其它强制属性提供覆盖值。
接收方将值指派给以下公共属性：
parentID(父ID)；
creationTime(创建时间)；
expirationTime(到期时间)：如果发起方没有提供，那么接收方指派可能的最大值(在接收方策略的限制内)。如果由于或者策略或者订阅限制而无法支持发起方提供的值，那么接收方将指派新值；
lastModifiedTime(最后修改时间)：其等于creationTime；以及
接收方策略的限制内的任何其它RO属性。
接收方检查creator(创建者)属性是否包括在请求的Content(内容)参数中。如果包括，那么creator属性在请求的Content参数中不能具有值。另一方面，如果creator属性不包括在请求的Content参数中，那么接收方不能在要创建的资源中包括creator属性。
在成功验证创建请求后，接收方创建所请求的资源；以及
接收方检查所创建的子资源是否导致其父资源的(一个或多个)属性的改变。如果是，那么更新父资源的(一个或多个)属性。
在步骤009中，接收方以强制参数进行响应，并且可以在针对CREATE操作的响应消息中发送可选参数。
一般例外：
发起方可能没有在接收方上创建资源的特权。在这种情况下，接收方可以以错误进行响应。
具有指定名称(如果提供的话)的资源已经存在于接收方处。在这种情况下，接收方可以以错误进行响应。
接收方不接受Content中提供的信息(例如，缺少强制参数)。在这种情况下，接收方可以以错误进行响应。
oneM2M LWM2M互通示例
图20示出了应用于检索LWM2M服务器信息对象资源的dejMinPeriod属性的如图14中所指定的示例性通用互通过程。图16提供了用于CSE的资源定义，以识别并允许创建和访问LWM2M服务器信息资源。另一方面，图18提供了用于LWM2M服务器信息资源的属性的重定标指示符以及用于协议翻译的数据模型映射信息。要注意的是，调用流程中仅包含有关的信息，以突出图14的数据模型映射和协议翻译方面。
在步骤0中，互配系统被配置并且可操作。这包括用于LWM2M服务器信息对象的资源定义和数据模型映射注册、LWM2M设备向LWM2M服务器/IPE注册、由IPE将LWM2M设备向CSE注册，以及创建LWM2M服务器信息资源(lwm2m1)和相关联的订阅，以及使得能够进行不同行动者之间的通信所需的所有其它配置。
在步骤1中，AE执行LWM2M服务器信息资源lwm2m1的deflAinPeriod属性的检索。
在步骤2中，CSE检查为defihiinPeriod属性提供的重定标指示符，如图18中所示。由于重定标指示符被设置为1(总是重定标)，因此CSE确定对请求进行重新标。
在步骤3中，CSE基于所创建的订阅向IPE发送消息。可替代地，CSE还可以使用与LWM2M设备相关联的AE资源的pointOfAccess属性来重定标消息或使用其中CSE向IPE通知重定标请求的另一种机制。
在步骤4中，在接收到消息后，IPE执行从oneM2M协议到LWM2M协议的请求的协议翻译。作为协议翻译的一部分，创建新的LWM2M消息，其中利用数据模型映射。defiviinPeriod属性基于图18中示出的映射被转换成LWM2M URI“/1/0/2”。在这种情况下，“0”是与lwm2m1资源相关联的实例编号。在创建lwm2m1资源时，IPE提供这个编号。
在步骤5中，IPE/LWM2M服务器然后将新创建的消息发送到LWM2M设备。消息“Get/1/0/2”是检索defiviinPeriod值的LWM2M请求。
在步骤6中，LWM2M设备返回具有适当值：86400的“2.05Content(内容)”响应代码。
在步骤7中，IPE在将LWM2M响应转换成oneM2M响应格式之后向CSE返回相同的值。
在步骤8中，CSE使用用于dejMinPeriod的重定标指示符来确定是否应当高速缓存该值以供将来使用。在这种情况下，没必要高速缓存，因为指示符被设置为总是重定标。
在步骤9中，CSE向AE返回适当的响应以及值86400。
oneM2M<flexContainer>XSD激活示例
oneM2M<flexContainer>资源提供指定XSD文件的位置的能力，以描述通过containerDefinition属性从基础<flexContainer>资源导出的新资源的内容。但是，oneM2M规范TS-0001没有规定CSE如何处理这种请求，并且已经识别出使用<flexContainer>资源的特化物列表。图21提供了如何可以集成<flexContainer>资源的创建的示例，以提供基于<flexContainer>资源注册并激活新资源定义的功能。这些新资源仍将被归类为<flexContainer>资源类型。因此，不需要资源定义。
在步骤1中，AE创建<flexContainer>资源并指定具有XSD文件的位置的URI的containerDefinition属性。
在步骤2中，CSE执行访问控制策略(ACP)检查，以确保AE可以创建<flexContainer>资源。此外，CSE还可以执行授权检查，以确保AE可以注册并激活该XSD文件，以防CSE的本地存储库中不存在该文件。
在步骤3中，如果ACP检查成功，那么CSE验证该请求以确保请求中存在所有所需信息。作为这种验证的一部分，CSE检查containerDefinition属性是否存在。
在步骤4中，如果来自步骤3的验证请求和来自步骤2的授权检查成功，那么CSE检查其本地储存库中是否存在与请求的有效载荷中提供的<flexContainer>资源匹配的XSD文件。
在步骤5中，如果从步骤4未找到匹配，那么CSE从containerDefinition属性中提取URI并从XSD储存库中提取XSD文件。
在步骤6中，CSE接收XSD文件。
在步骤7中，作为激活过程的一部分，CSE检查XSD文件是被良好格式化的。
在步骤8中，如果XSD文件被良好格式化，那么CSE将XSD文件保存到其本地储存库以供将来使用。
在步骤9中，CSE还更新CSE基础资源处的supportedResourceType属性。
在步骤10中，CSE对照XSD验证所请求的资源。
在步骤11中，如果所有先前的检查都成功，那么CSE创建<flexContainer>资源。
在步骤12中，CSE取决于这个过程中检查的状态发送适当的响应。
多供应商互通示例
图22示出了将其设备与CSE互通的两个供应商的示例，如下面所讨论的。通过这样做，每个供应商可以将其服务提供给公共服务层平台并提供其产品供给的差异化。然后，AE可以发现并访问这些资源，以从每个供应商处获得服务，而无需理解每个供应商的数据模型。
在步骤0中，互通系统被配置并且可操作，其中所有CSE注册(IPE和AE)都完成并成功。供应商A和B使用资源定义和数据模型映射注册过程将其资源与CSE互通。AE已发现两个供应商的资源并希望访问它们。
在步骤1中，AE执行对供应商A资源的请求。
在步骤2中，CSE检查重定标指示符并确定将请求重定标到供应商A/IPE。
在步骤3中，CSE将重定标的请求发送到供应商A/IPE并接收响应。
在步骤4中，CSE用来自供应商A的资源的数据返回对AE的响应。
在步骤5-8中，对供应商B的资源重复步骤1到4。
图22中所示的示例与图6中给出的示例非常相似，主要区别在于后者涉及不同系统之间的互通，而前者可以涉及不同领域或甚至同一领域中的各供应商。在每种情况下，应用都可以使用本机服务层过程无缝访问这些不同的资源。
智能重定标互通示例
在另一个示例中，LWM2M架构允许多个LWM2M服务器管理相同的LWM2M客户端或设备。在互通场景中，可能存在管理同一个设备的两个LWM2M服务器，一个服务器具有传统的LWM2M服务器，并且另一个服务器具有与IPE集成的LWM2M服务器。图23示出了这种示例场景，其中LWM2M服务器1是传统服务器，并且LWM2M服务器2是互通服务器，如下面所讨论的。在这个示例中，两个LWM2M服务器都成激活状态地(actively)管理LWM2M设备。LWM2M服务器2/IPE已为固件更新(Firmware Update)对象的固件版本资源配置了“在更新时改变”的重定标指示符。因此，LWM2M服务器2已经发出了观察请求以获得FW更新的通知。
在步骤0中，互通系统被配置并且可操作，其中所有CSE注册都完成并成功。LWM2M设备由传统的LWM2M服务器1和互通LWM2M服务器2管理。与IPE集成的LWM2M服务器2可以观察LWM2M设备的固件版本资源，并知道固件更新何时执行并成功。因此，IPE支持在CSE上保持更新的固件版本属性，并将相关联的数据模型映射配置为一次重定标。
在步骤1中，LWM2M服务器1在LWM2M设备上执行固件更新并接收成功响应。
在步骤2中，LWM2M设备向LWM2M服务器2发送具有新固件版本的通知。
在步骤3中，IPE基于重定标指示符确定更新CSE上的固件版本。
在步骤4中，IPE用新版本号更新CSE上的固件版本属性。
用户接口
图24示出了示例用户接口，其中服务层显示在服务器内注册的资源定义。可替代地，在发现资源定义并检索LWM2M：1定义文档之后，资源定义可以由SL应用显示。用户接口在窗口的左窗格上示出了资源定义的列表，其具有定义名称和版本号以及互通标准的徽标。图24示出了用户选择LWM2M：1资源定义，该定义被突出显示。在窗口的右窗格上，示出了LWM2M：1的资源定义的内容。可以使用类似的显示来示出数据模型映射文档。
示例环境
应当理解的是，图9-14和19-23的步骤可以由那些图中描绘的相应实体执行，这些实体可以表示通信网络中的逻辑实体并且可以以存储在这种网络的装置的存储器中并在所述装置的处理器上执行的软件(即，计算机可执行指令)的形式实现，其可以包括下面更全面描述的图25C或25D中所示的一般架构之一。即，图9-14和19-23中所示的操作可以以存储在网络装置的存储器中的软件(即，计算机可执行指令)的形式实现，诸如例如具有图25C或25D所示的架构之一的网络装置，当由装置的处理器执行时，计算机可执行指令执行图中所示的步骤。还应理解的是，图9-14和19-23中所示的任何发送和接收步骤可以在装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下由装置的通信电路系统(例如，图25C和25D的电路系统34或97)执行。
图25A是示例性机器到机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图，其中可以实现一个或多个公开的实施例。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等的部件或装置。图1、4-15和19-23中任何一个中所示的实体中的任何一个都可以包括通信系统的网络装置，诸如图25A-25D中所示的那些。
服务层可以是网络服务架构内的功能层。服务层通常位于应用协议层(诸如HTTP、CoAP或MQTT)之上，并为客户端应用提供增值服务。服务层还提供到位于较低资源层(诸如例如控制层和运输/接入层)的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层，以解决与将M2M类型的设备和应用集成到诸如因特网/web、蜂窝、企业和家庭网络的部署中相关联的挑战。M2M服务层可以为应用和/或各种设备提供对由服务层支持的上面提到的能力或功能集合或集的访问，服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、计费、数据管理、设备管理、发现、供应以及连接性管理，这些能力或功能可以被各种应用共同使用。经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API，使这些能力或功能能够用于所述各种应用。CSE或SCL是可以由硬件或软件实现的功能实体，并且提供暴露于各种应用或设备的(服务)能力或功能(即，这种功能实体之间的功能接口)，以便它们使用这种能力或功能。
如图25A中所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。另外，例如，通信网络12可以包括其它网络，诸如核心网、互联网、传感器网络、工业控制网络、个域网、融合个人网络、卫星网络、家庭网络或企业网络之类。
如图25A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域(FieldDomain)。基础设施域是指端到端M2M部署的网络侧，并且场域是指通常在M2M网关后面的区域网络。场域和基础设施域都可以包括网络的各种不同网络装置(例如，服务器、网关、设备等)。例如，场域可以包括M2M网关14和设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M设备18可以包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M设备18中的每一个被配置为使用通信电路系统经由通信网络12或直接无线电链路发送和接收信号。
M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)或者通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M设备18可以收集数据并经由通信网络12或直接无线电链路向M2M应用20或其它M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20接收，如下所述。M2M设备18和网关14可以经由各种网络进行通信，包括蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。示例性M2M设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。
参考图25B，场域中所示的M2M服务层22为M2M应用20、M2M网关14和M2M设备18以及通信网络12提供服务。将理解的是，M2M服务层22可以根据期望与任何数量的M2M应用、M2M网关14、M2M设备18和通信网络12通信。M2M服务层22可以由网络的一个或多个网络装置实现，这些网络装置可以包括服务器、计算机、设备等。M2M服务层22提供适用于M2M设备18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如作为web服务器、在蜂窝核心网中、在云中等等。
类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为场域中的M2M网关14和M2M设备18提供服务。将理解的是，M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M设备通信。M2M服务层22'可以与不同的服务提供商的服务层交互。M2M服务层22'可以由网络的一个或多个网络装置实现，所述网络装置可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。
还参考图25B，M2M服务层22和22'提供不同应用和行业(vertical)可以充分利用的核心服务递送能力集。这些服务功能使M2M应用20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。基本上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过各种网络(诸如网络12)与服务层22和22'提供的服务相关联地进行通信。
M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全性和监控。如上面所提到的，在系统的设备、网关、服务器和其它网络装置之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及传统系统集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。
一般而言，诸如图25B中所示的服务层22和22'之类的服务层定义软件中间件层，该软件中间件层通过应用编程接口(API)和底层联网接口的集合来支持增值服务能力。ETSI M2M和oneM2M架构都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在ETSI M2M架构的各种不同节点中实现。例如，服务层的实例可以在M2M设备中实现(其中它被称为设备SCL(DSCL))、在网关中实现(其中它被称为网关SCL(GSCL))和/或在网络节点中实现(其中它被称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)的集合(即，服务能力)。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。第三代合作伙伴计划(3GPP)还已经定义了用于机器类型通信(MTC)的架构。在那种架构中，服务层及其提供的服务能力是作为服务能力服务器(SCS)的一部分实现的。无论是在ETSI M2M架构的DSCL、GSCL或NSCL中实施，在3GPP MTC架构的服务能力服务器(SCS)中实施，在oneM2M架构的CSF或CSE中实施，还是在网络的某个其它节点中实施，服务层的实例都可以被实现为或者在网络中的一个或多个独立节点(包括服务器、计算机以及其它计算设备或节点)上执行的逻辑实体(例如，软件、计算机可执行指令等)，或者被实现为一个或多个现有节点的一部分。作为示例，服务层或其部件的实例可以以在具有下述图25C或图25D中所示的一般架构的网络装置(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现。
另外，本文描述的方法和功能可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务的M2M网络的一部分。
图25C是网络的装置的示例硬件/软件架构的框图，其中装置诸如图1、4-15和19-23中所示的实体之一，其可以作为诸如图25A和25B中所示的M2M网络中的M2M服务器、网关、设备或其它网络装置操作。如图25D中所示，网络装置30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。网络装置30还可以包括通信电路系统，诸如收发器34和发送/接收元件36。将认识到的是，网络装置30可以包括前述元件的任意子组合，同时保持与实施例一致。这个网络装置可以是实现本文描述的消息模板管理能力和方法(诸如关于图9-14和19-23示出和描述的方法)的装置。
处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般而言，处理器32可以执行存储在网络装置的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行网络装置的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使网络装置30能够在无线或有线环境中操作的任何其它功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。例如，处理器32还可以执行安全操作，诸如认证、安全密钥协商和/或加密操作之类，诸如在接入层和/或应用层处。
如图25C中所示，处理器32耦合到其通信电路系统(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统，以便使网络装置30经由与其连接的网络与其它网络装置通信。特别地，处理器32可以控制通信电路系统，以便执行本文和权利要求中描述的发送和接收步骤(例如，在图9-14和19-23中)。虽然图25C将处理器32和收发器34描绘为分开的部件，但是将认识到的是，处理器32和收发器34可以一起集成在电子包或芯片中。
发送/接收元件36可以被配置为向其它网络装置发送信号或从其它网络装置接收信号，所述网络装置包括M2M服务器、网关、设备等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置为例如发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。将认识到的是，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任意组合。
此外，虽然发送/接收元件36在图25C中被描绘为单个元件，但是网络装置30可以包括任何数量的发送/接收元件36。更具体而言，网络装置30可以采用MIMO技术。因此，在实施例中，网络装置可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。
收发器34可以被配置为调制将由发送/接收元件36发送的信号并且解调由发送/接收元件36接收的信号。如上所述，网络装置30可以具有多模式能力。因此，例如，收发器34可以包括多个收发器，用于使网络装置30能够经由多个RAT(诸如UTRA和IEEE 802.11)进行通信。
处理器32可以从任何类型的合适存储器(诸如不可移除存储器44和/或可移除存储器46)访问信息，并将数据存储在其中。例如，处理器32可以在其存储器中存储会话上下文，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘，或任何其它类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从物理地位于网络装置30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色以反映装置的状态或配置装置，并且特别是底层网络、应用或与网络装置通信的其它服务。在一个实施例中，显示器/指示器42可以呈现图24中所示并在本文描述的图形用户接口。
处理器32可以从电源48接收电力，并且可以被配置为向网络装置30中的其它部件分配和/或控制电力。电源48可以是用于为网络装置30供电的任何合适的设备。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32还可以耦合到GPS芯片组50，GPS芯片组50被配置为提供关于网络装置30的当前位置的位置信息(例如，经度和纬度)。将认识到的是，网络装置30可以通过任何合适的位置确定方法获取位置信息，同时保持与实施例一致。
处理器32还可以耦合到其它外围设备52，外围设备52可以包括提供附加特征、功能和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物测定(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等等。
网络装置30可以在其它装置或设备中实施，诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子卫生设备、机器人、工业装备、无人机、车辆(诸如小汽车、卡车、火车或飞机)之类。网络装置30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。
图25D是示例性计算系统90的框图，该计算机系统90还可以用于实现网络的一个或多个网络装置，诸如图1、4-15和19-23中所示并在本文描述的实体，其可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置操作，诸如图25A和25B所示。
计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，计算机可读指令可以是软件的形式，无论在何处，或者通过任何方式存储或访问这样的软件。这种计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。
在操作中，CPU 91提取、解码并执行指令，并经由计算机的主数据传输路径，系统总线80，向其它资源传送信息和从其它资源传送信息。这种系统总线连接计算系统90中的部件并定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线，以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围部件互连)总线。
耦合到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路系统。ROM 93一般包含不能被容易地修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其它硬件设备读取或改变。对RAM 82和/或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，该地址翻译功能在执行指令时将虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，该存储器保护功能隔离系统内的进程并将系统进程与用户进程隔离。因此，以第一模式运行的程序只可以访问由其自己的进程虚拟地址空间映射的存储器；除非已设置进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。
此外，计算系统90可以包含外围设备控制器83，其负责将来自CPU 91的指令传送到外围设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85。
由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示控制器96包括生成发送到显示器86的视频信号所需的电子部件。结合由CPU 91执行的计算机可执行指令，显示器86可以生成并操作图25及其随附的描述中所示并描述的图形用户接口。
另外，计算系统90可以包含通信电路系统，诸如例如网络适配器97，其可以用于将计算系统90连接到外部通信网络，诸如图25A-25D的网络12，以使计算系统90能够与网络的其它装置通信。单独或与CPU 91组合，通信电路系统可以用于执行本文(例如，在图9-14和19-23中)和权利要求中描述的发送和接收步骤。
应该理解的是，本文描述的任何或所有系统、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，所述指令在由机器(诸如M2M网络的装置，包括例如M2M服务器、网关、设备等)执行时执行和/或实现本文描述的系统、方法和处理。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何非瞬态(即，有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字通用盘(DVD)或其它光盘存储装置，磁带盒、磁带、磁盘存储装置或其它磁存储设备，或者可以用于存储期望信息并且可由计算机访问的任何其它有形或物理介质。
本书面描述使用示例来公开本发明，包括最佳模式，并且还使任何本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有与权利要求的字面语言没有不同的元素，或者如果它们包括与权利要求的字面语言无实质差别的等效元素，那么这些其它示例意图在权利要求的范围内。

Claims (44)

1.一种用于服务层资源管理的装置，包括处理器、存储器和通信电路系统，所述装置经由所述装置的通信电路系统连接到网络，所述装置还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使得所述装置执行包括以下的操作：
在服务层处接收注册信息的请求，所述信息定义资源实例的新的定制资源类型，所述资源实例被存储为服务层资源树中的条目，
其中所述新的定制资源类型在服务层处当前不可用，并且
其中所述新的定制资源类型包括一个或多个定制资源属性，并且所述一个或多个定制资源属性指定对应定制资源类型的数据模型；
将所述信息集成到服务层的操作中；以及
暴露所述信息以供在网络上通信的其它网络装置发现。
2.如权利要求1所述的装置，其中所述信息包括资源定义文档。
3.如权利要求2所述的装置，其中资源定义文档包括关于资源定义的信息、继承的资源属性、特定于资源的属性、子资源属性或激活标准中的至少一个。
4.如权利要求1所述的装置，还包括在服务层处管理所述信息。
5.如权利要求4所述的装置，其中管理所述信息包括在服务层处所述信息的检索、更新、移除、激活和停用中的至少一个。
6.如权利要求5所述的装置，其中激活所述信息触发服务层处的授权检查，以确保请求者被授权请求对所述信息的激活。
7.如权利要求1所述的装置，还包括基于在服务层处对所述信息的评估来生成响应。
8.如权利要求1所述的装置，其中在服务层处接收所述信息包括在服务层内的虚拟或物理资源处接收所述信息。
9.如权利要求1所述的装置，其中在服务层处接收所述信息包括在服务层处接收第一统一资源指示符URI。
10.如权利要求9所述的装置，还包括经由第一URI在服务层处下载所述信息。
11.如权利要求1所述的装置，还包括基于所述信息在服务层处生成对应的模式文档。
12.如权利要求11所述的装置，其中模式文档存储在只能由服务层和服务层管理员访问的储存库中。
13.如权利要求1所述的装置，还包括：
接收注册数据的请求，所述数据为与第三方设备相关联的资源提供到与服务层相关联的资源类型或资源的一对一映射，与第三方设备相关联的资源是根据与定义和服务层相关联的资源的协议不同的协议来定义的；以及
将所述数据向服务层注册。
14.一种用于服务层资源管理的方法，包括：
在服务层处接收注册信息的请求，所述信息定义资源实例的新的定制资源类型，所述资源实例被存储为服务层资源树中的条目，
其中所述新的定制资源类型在服务层处当前不可用，并且
其中所述新的定制资源类型包括一个或多个定制资源属性，并且所述一个或多个定制资源属性指定对应定制资源类型的数据模型；
将所述信息集成到服务层的操作中；以及
暴露所述信息以供在网络上通信的其它网络装置发现。
15.如权利要求14所述的方法，其中所述信息包括资源定义文档。
16.如权利要求15所述的方法，其中资源定义文档包括关于资源定义的信息、继承的资源属性、特定于资源的属性、子资源属性或激活标准中的至少一个。
17.如权利要求14所述的方法，还包括在服务层处管理所述信息。
18.如权利要求17所述的方法，其中管理所述信息包括在服务层处所述信息的检索、更新、移除、激活和停用中的至少一个。
19.如权利要求18所述的方法，其中激活所述信息触发服务层处的授权检查，以确保请求者被授权请求对所述信息的激活。
20.如权利要求14所述的方法，还包括基于在服务层处对所述信息的评估来生成响应。
21.如权利要求14所述的方法，其中在服务层处接收所述信息包括在服务层内的虚拟或物理资源处接收所述信息。
22.如权利要求14所述的方法，其中在服务层处接收所述信息包括在服务层处接收第一统一资源指示符URI。
23.如权利要求22所述的方法，还包括经由第一URI在服务层处下载所述信息。
24.如权利要求14所述的方法，还包括基于所述信息在服务层处生成对应的模式文档。
25.如权利要求24所述的方法，其中模式文档存储在只能由服务层和服务层管理员访问的储存库中。
26.如权利要求14所述的方法，还包括：
接收注册数据的请求，所述数据为与第三方设备相关联的资源提供到与服务层相关联的资源类型或资源的一对一映射，与第三方设备相关联的资源是根据与定义和服务层相关联的资源的协议不同的协议来定义的；以及
将所述数据向服务层注册。
27.一种用于服务层资源管理的装置，包括用于执行如权利要求14-26中任一项所述的方法的部件。
28.一种其上存储有计算机程序的计算机可读存储介质，所述计算机程序包括指令，所述指令在被处理器执行时，使所述处理器实现如权利要求14-26中任一项所述的方法。
29.一种用于服务层资源管理的装置，包括处理器、存储器和通信电路系统，所述装置经由所述装置的通信电路系统连接到网络，所述装置还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使所述装置执行包括以下的操作：
在网络的服务层处接收检索与服务层相关联的定制资源的请求，所述定制资源属于资源实例的定制资源类型，所述资源实例被存储为服务层资源树中的条目，并且所述定制资源类型由服务层能够访问的信息来定义，其中所述定制资源类型包括一个或多个定制资源属性，并且所述一个或多个定制资源属性指定对应定制资源类型的数据模型；
确定为了访问所述定制资源而需要互通；以及
在服务层处访问包括所述定制资源类型的所述一个或多个定制资源属性的所述定制资源的信息，和将所述定制资源映射到与第三方设备相关联的所述一个或多个定制资源属性中的至少一个资源属性的数据，所述至少一个资源属性是根据与定义和服务层相关联的资源的协议不同的协议来定义的。
30.如权利要求29所述的装置，其中将所述定制资源映射到与第三方设备相关联的所述一个或多个定制资源属性中的所述至少一个资源属性的数据包括多个不同指示符中的一个。
31.如权利要求30所述的装置，其中所述多个指示符中的每一个指示符指示服务层能够重定标检索所述至少一个资源属性的请求的方式。
32.如权利要求31所述的装置，还包括评估响应于请求而高速缓存的数据是否可用于所请求的资源属性，并且如果不可用，那么根据所访问的数据中的指示符重定标接收到的请求。
33.如权利要求32所述的装置，其中所述多个指示符包括：
第一指示符，指示服务层仅检索一次资源并保存该资源以供将来使用；
第二指示符，指示服务层在每次接收到检索资源的请求时检索资源；
第三指示符，指示服务层在事件发生后检索资源；以及
第四指示符，指示服务层定期检索资源。
34.如权利要求32所述的装置，还包括接收具有针对所请求的资源属性的数据的响应，并保存所述数据以供将来使用。
35.如权利要求32所述的装置，其中所述数据包括数据模型映射文档，所述数据模型映射文档被注册到服务层。
36.一种用于服务层资源管理的方法，包括：
在网络的服务层处接收检索与服务层相关联的定制资源的请求，所述定制资源属于资源实例的定制资源类型，所述资源实例被存储为服务层资源树中的条目，并且所述定制资源类型由服务层能够访问的信息来定义，其中所述定制资源类型包括一个或多个定制资源属性，并且所述一个或多个定制资源属性指定对应定制资源类型的数据模型；
确定为了访问所述定制资源而需要互通；以及
在服务层处访问包括所述定制资源类型的所述一个或多个定制资源属性的所述定制资源的信息，和将所述定制资源映射到与第三方设备相关联的所述一个或多个定制资源属性中的至少一个资源属性的数据，所述至少一个资源属性是根据与定义和服务层相关联的资源的协议不同的协议来定义的。
37.如权利要求36所述的方法，其中将所述定制资源映射到与第三方设备相关联的所述一个或多个定制资源属性中的所述至少一个资源属性的数据包括多个不同指示符中的一个。
38.如权利要求37所述的方法，其中所述多个指示符中的每一个指示符指示服务层能够重定标检索所述至少一个资源属性的请求的方式。
39.如权利要求38所述的方法，还包括评估响应于请求而高速缓存的数据是否可用于所请求的资源属性，并且如果不可用，那么根据所访问的数据中的指示符重定标接收到的请求。
40.如权利要求39所述的方法，其中所述多个指示符包括：
第一指示符，指示服务层仅检索一次资源并保存该资源以供将来使用；
第二指示符，指示服务层在每次接收到检索资源的请求时检索资源；
第三指示符，指示服务层在事件发生后检索资源；以及
第四指示符，指示服务层定期检索资源。
41.如权利要求39所述的方法，还包括接收具有针对所请求的资源属性的数据的响应，并保存所述数据以供将来使用。
42.如权利要求39所述的方法，其中所述数据包括数据模型映射文档，所述数据模型映射文档被注册到服务层。
43.一种用于服务层资源管理的装置，包括用于执行如权利要求36-42中任一项所述的方法的部件。
44.一种其上存储有计算机程序的计算机可读存储介质，所述计算机程序包括指令，所述指令在被处理器执行时，使所述处理器实现如权利要求36-42中任一项所述的方法。
CN201780071831.XA 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理 Active CN109997114B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311218363.8A CN117170876A (zh) 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662405534P 2016-10-07 2016-10-07
US62/405,534 2016-10-07
PCT/US2017/055552 WO2018067939A1 (en) 2016-10-07 2017-10-06 Service layer resource management for generic interworking and extensibility

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202311218363.8A Division CN117170876A (zh) 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理

Publications (2)

Publication Number Publication Date
CN109997114A CN109997114A (zh) 2019-07-09
CN109997114B true CN109997114B (zh) 2023-09-29

Family

ID=60183119

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202311218363.8A Pending CN117170876A (zh) 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理
CN201780071831.XA Active CN109997114B (zh) 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202311218363.8A Pending CN117170876A (zh) 2016-10-07 2017-10-06 用于通用互通和可扩展性的服务层资源管理

Country Status (6)

Country Link
US (3) US11240093B2 (zh)
EP (1) EP3523724B1 (zh)
JP (1) JP7090603B2 (zh)
KR (2) KR102389004B1 (zh)
CN (2) CN117170876A (zh)
WO (1) WO2018067939A1 (zh)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10547519B2 (en) * 2016-11-02 2020-01-28 Servicenow, Inc. System and method of associating metadata with computing resources across multiple providers
US11204815B2 (en) 2017-05-09 2021-12-21 Microsoft Technology Licensing, Llc Creation of modular applications with corresponding twins in the cloud
US11483418B2 (en) * 2017-12-06 2022-10-25 Intel Corporation Plugin management for internet of things (IoT) network optimization
US11695841B2 (en) * 2018-01-03 2023-07-04 Convida Wireless, Llc Cross-domain discovery between service layer systems and web of Things systems
CN110858846A (zh) * 2018-08-22 2020-03-03 京东方科技集团股份有限公司 资源配置方法、装置和存储介质
US11121932B2 (en) * 2019-04-10 2021-09-14 Cisco Technology, Inc. Method and apparatus for model mapping and dynamically enabling external model on the network device
JP2020195122A (ja) * 2019-05-30 2020-12-03 京セラ株式会社 通信機器及びその制御方法
WO2021146960A1 (zh) * 2020-01-21 2021-07-29 Oppo广东移动通信有限公司 消息端点发现方法及相关装置
EP4186217A1 (en) * 2020-07-22 2023-05-31 Telefonaktiebolaget LM Ericsson (publ) Provision of network access information for a computing device
CN111885058B (zh) * 2020-07-23 2022-05-13 伊拉克巴士拉大学 物联网云中端到端智能设备通信的轻量级消息传递方法
CN112558968B (zh) * 2020-12-22 2023-10-17 北京飞讯数码科技有限公司 一种资源树视图的生成方法、装置、设备及存储介质
CN113259443B (zh) * 2021-05-20 2023-09-29 远景智能国际私人投资有限公司 资源数据的更新系统、方法、装置、设备及可读存储介质
US11799737B1 (en) 2021-06-30 2023-10-24 Juniper Networks, Inc. Topology-based graphical user interface for network management systems
CN113626189B (zh) * 2021-08-03 2024-02-06 优刻得科技股份有限公司 资源管理模型的构建方法、设备和介质
US11425221B1 (en) * 2021-09-03 2022-08-23 Juniper Networks, Inc. Runtime extensible application programming interface server
WO2023068394A1 (ko) * 2021-10-19 2023-04-27 한국전자기술연구원 원엠투엠 시스템과 엔지에스아이-엘디 시스템 간의 데이터 연동 방법
WO2023080261A1 (ko) * 2021-11-02 2023-05-11 한국전자기술연구원 시맨틱 온톨로지를 활용한 원엠투엠과 엔지에스아이-엘디 표준 플랫폼 간 연동 방법
KR102560613B1 (ko) * 2022-11-29 2023-07-27 부산대학교 산학협력단 oneM2M과 LWM2M와의 연동을 위한 블록체인 기반 플랫폼 시스템 및 블록체인 기반 플랫폼 구현 방법
US11949802B1 (en) 2022-11-29 2024-04-02 Pusan National University Industry-University Cooperation Foundation Blockchain-based platform system for interworking with one machine-to-machine(oneM2M) and lightweight machine-to-machine (LWM2M), and method of implementing blockchain-based platform

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102576354A (zh) * 2009-07-31 2012-07-11 电子湾有限公司 支持不同部署架构的可扩展框架
KR20130053202A (ko) * 2011-11-15 2013-05-23 주식회사 케이티 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치
WO2015143086A1 (en) * 2014-03-18 2015-09-24 Zte Corporation Resource and attribute management in machine to machine networks
WO2016044581A1 (en) * 2014-09-17 2016-03-24 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
CN105580396A (zh) * 2013-09-27 2016-05-11 Lg电子株式会社 用于在m2m系统中传送通知消息的方法及其装置
CN105766005A (zh) * 2013-10-24 2016-07-13 康维达无线有限责任公司 服务覆盖管理系统和方法
WO2016153997A1 (en) * 2015-03-20 2016-09-29 Convida Wireless, Llc Methods to support message routing at service layer

Family Cites Families (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6714987B1 (en) * 1999-11-05 2004-03-30 Nortel Networks Limited Architecture for an IP centric distributed network
US7496652B2 (en) * 2000-07-17 2009-02-24 Teleservices Solutions, Inc. Intelligent network providing network access services (INP-NAS)
US6910074B1 (en) * 2000-07-24 2005-06-21 Nortel Networks Limited System and method for service session management in an IP centric distributed network
US7584274B2 (en) * 2004-06-15 2009-09-01 International Business Machines Corporation Coordinating use of independent external resources within requesting grid environments
US20110016214A1 (en) * 2009-07-15 2011-01-20 Cluster Resources, Inc. System and method of brokering cloud computing resources
US8935429B2 (en) * 2006-12-19 2015-01-13 Vmware, Inc. Automatically determining which remote applications a user or group is entitled to access based on entitlement specifications and providing remote application access to the remote applications
US20080021918A1 (en) * 2005-12-23 2008-01-24 Rao Viswanatha H Enterprise service management unifier system
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US20070209042A1 (en) * 2006-03-01 2007-09-06 France Telecom Grid computing architecture & associated method of invoking/registering network services for subscription
US8468338B2 (en) * 2006-07-06 2013-06-18 Apple, Inc. Wireless access point security for multi-hop networks
US8234702B2 (en) * 2006-08-29 2012-07-31 Oracle International Corporation Cross network layer correlation-based firewalls
US8804534B2 (en) * 2007-05-19 2014-08-12 Cisco Technology, Inc. Interworking between MPLS/IP and Ethernet OAM mechanisms
US7961711B2 (en) * 2007-08-06 2011-06-14 Microsoft Corporation Fitness based routing
CN101309227B (zh) * 2008-07-17 2011-11-30 中兴通讯股份有限公司 一种家庭网关策略控制的装置、系统及其实现方法
US8250215B2 (en) * 2008-08-12 2012-08-21 Sap Ag Method and system for intelligently leveraging cloud computing resources
US8244559B2 (en) * 2009-06-26 2012-08-14 Microsoft Corporation Cloud computing resource broker
US9246953B2 (en) * 2009-11-19 2016-01-26 Oracle International Corporation Protocol level communications for protocol level composition with session sharing
US9519728B2 (en) * 2009-12-04 2016-12-13 Time Warner Cable Enterprises Llc Apparatus and methods for monitoring and optimizing delivery of content in a network
GB2477092A (en) * 2010-01-20 2011-07-27 Nec Corp Selecting virtual machine host servers based on client device location
JP5589098B2 (ja) * 2010-03-09 2014-09-10 インターデイジタル パテント ホールディングス インコーポレイテッド 機器対機器通信をサポートするための方法および装置
US9215079B2 (en) * 2010-04-18 2015-12-15 Tropo, Inc. Servlet API and method for XMPP protocol
CN102238573A (zh) * 2010-04-30 2011-11-09 中兴通讯股份有限公司 一种m2m业务的架构及实现m2m业务的方法
WO2012013401A1 (en) * 2010-07-27 2012-02-02 Telefonaktiebolaget L M Ericsson (Publ) Machine-type communication subscription control
US9239996B2 (en) * 2010-08-24 2016-01-19 Solano Labs, Inc. Method and apparatus for clearing cloud compute demand
US8806486B2 (en) * 2010-09-03 2014-08-12 Time Warner Cable Enterprises, Llc. Methods and systems for managing a virtual data center with embedded roles based access control
CN102136933B (zh) * 2010-09-30 2013-08-28 华为技术有限公司 设备管理方法、中间件及机器通信平台、设备和系统
US8756323B2 (en) * 2010-11-26 2014-06-17 International Business Machines Corporation Semantic- and preference-based planning of cloud service templates
US8527633B2 (en) * 2011-01-06 2013-09-03 International Business Machines Corporation Techniques for addressing geographical location issues in computing environments
CN107529693B (zh) * 2011-02-11 2020-08-21 Iot控股公司 用于管理机器对机器(m2m)实体的系统、方法和设备
EP2698032A1 (en) * 2011-04-11 2014-02-19 Interdigital Patent Holdings, Inc. Session manager and source internet protocol (ip) address election
US9336060B2 (en) * 2011-06-17 2016-05-10 Microsoft Technology Licensing, Llc Middleware services framework for on-premises and cloud deployment
US8793378B2 (en) * 2011-09-01 2014-07-29 International Business Machines Corporation Identifying services and associated capabilities in a networked computing environment
US9781205B2 (en) * 2011-09-12 2017-10-03 Microsoft Technology Licensing, Llc Coordination engine for cloud selection
TWI625048B (zh) * 2011-10-24 2018-05-21 內數位專利控股公司 在複數服務層之間機器到機器（m2m）通信的方法、系統及裝置
CN103200209B (zh) * 2012-01-06 2018-05-25 华为技术有限公司 成员资源的访问方法、群组服务器和成员设备
TWI613897B (zh) * 2012-02-03 2018-02-01 內數位專利控股公司 支援m2m內容及上下文為基礎服務的方法及裝置
US9508102B2 (en) * 2012-07-25 2016-11-29 Facebook, Inc. Methods and systems for tracking of user interactions with content in social networks
US9106561B2 (en) * 2012-12-06 2015-08-11 A10 Networks, Inc. Configuration of a virtual service network
WO2014088340A1 (ko) * 2012-12-05 2014-06-12 엘지전자 주식회사 무선 통신 시스템에서 접근 권한 인증을 위한 방법 및 장치
KR101467173B1 (ko) * 2013-02-04 2014-12-01 주식회사 케이티 Ｍ２ｍ 네트워크의 리소스 관리 방법 및 리소스 관리 장치
US9800999B2 (en) * 2013-02-19 2017-10-24 Lg Electronics Inc. Method for modifying M2M service setting and apparatus therefor
KR101538714B1 (ko) * 2013-02-26 2015-07-22 주식회사 케이티 Ｍ２ｍ 네트워크를 이용하는 복수의 디바이스간 상관관계 분석을 통한 네트워크 운영 방법 및 시스템
US9716634B2 (en) * 2013-03-15 2017-07-25 International Business Machines Corporation Fulfillment of cloud service orders
WO2014182694A1 (en) * 2013-05-06 2014-11-13 Convida Wireless LLC Device triggering
EP3000249B1 (en) * 2013-05-22 2020-07-08 Convida Wireless, LLC Access network assisted bootstrapping
EP3005659B1 (en) * 2013-05-28 2019-07-10 Convida Wireless, LLC Load balancing in the internet of things
CN105474670B (zh) * 2013-07-24 2020-08-18 康维达无线有限责任公司 服务域收费系统和方法
US10200353B2 (en) * 2013-07-25 2019-02-05 Convida Wireless, Llc End-to-end M2M service layer sessions
GB2586549B (en) * 2013-09-13 2021-05-26 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
JP2016537835A (ja) * 2013-09-20 2016-12-01 コンヴィーダ ワイヤレス， エルエルシー 近接サービスおよびモノのインターネットサービスのためのジョイント登録または登録解除の方法
US9401954B2 (en) * 2013-11-06 2016-07-26 International Business Machines Corporation Scaling a trusted computing model in a globally distributed cloud environment
KR20160091314A (ko) * 2013-11-29 2016-08-02 엘지전자 주식회사 무선 통신 시스템에서 서비스 구독 리소스 기반 인증 방법
CN106797391B (zh) * 2014-07-21 2020-05-19 康维达无线有限责任公司 使用mqtt协议的服务层交互工作
US9445248B2 (en) * 2014-07-25 2016-09-13 Qualcomm Incorporated Radio-agnostic message translation service
US9459903B2 (en) * 2014-09-24 2016-10-04 Intel Corporation Techniques for routing service chain flow packets between virtual machines
CN105611484B (zh) * 2014-11-03 2020-07-10 中兴通讯股份有限公司 一种m2m节点的管理方法和装置
WO2016109521A1 (en) * 2014-12-30 2016-07-07 Convida Wireless, Llc Semantics annotation and semantics repository for m2m systems
US20170064488A1 (en) * 2015-08-26 2017-03-02 Qualcomm Incorporated Customized resource types for machine-to-machine communication
WO2017061916A1 (en) * 2015-10-09 2017-04-13 Telefonaktiebolaget Lm Ericsson (Publ) Network node, wireless device and methods performed thereby for the network node to provide information to the wireless device
CN111885508B (zh) * 2015-12-15 2022-04-12 华为云计算技术有限公司 一种群组多播和群组创建的方法以及移动网络平台
US10042685B1 (en) * 2017-03-17 2018-08-07 Accenture Global Solutions Limited Extensible single point orchestration system for application program interfaces

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102576354A (zh) * 2009-07-31 2012-07-11 电子湾有限公司 支持不同部署架构的可扩展框架
KR20130053202A (ko) * 2011-11-15 2013-05-23 주식회사 케이티 Ｍ２ｍ 통신 개체간 통지 기능을 구현하는 방법 및 장치
CN105580396A (zh) * 2013-09-27 2016-05-11 Lg电子株式会社 用于在m2m系统中传送通知消息的方法及其装置
CN105766005A (zh) * 2013-10-24 2016-07-13 康维达无线有限责任公司 服务覆盖管理系统和方法
WO2015143086A1 (en) * 2014-03-18 2015-09-24 Zte Corporation Resource and attribute management in machine to machine networks
WO2016044581A1 (en) * 2014-09-17 2016-03-24 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
WO2016153997A1 (en) * 2015-03-20 2016-09-29 Convida Wireless, Llc Methods to support message routing at service layer

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Jaeseok Yun等.Demo: Towards Global Interworking of IoT Systems -- oneM2M Interworking Proxy Entities.《SenSys '15: Proceedings of the 13th ACM Conference on Embedded Networked Sensor Systems》.2015,473–474. *
物联网关键技术与应用;刘强;《计算机科学》;20100615;第37卷(第6期);1-4 *
物联网服务支撑系统的研究与实现;张楚天;《中国优秀硕士学位论文全文数据库 信息科技辑》(第1期);I138-1240 *

Also Published As

Publication number Publication date
JP7090603B2 (ja) 2022-06-24
KR20190065372A (ko) 2019-06-11
CN117170876A (zh) 2023-12-05
CN109997114A (zh) 2019-07-09
US20240080235A1 (en) 2024-03-07
KR102389004B1 (ko) 2022-04-22
US20180102934A1 (en) 2018-04-12
WO2018067939A1 (en) 2018-04-12
US20220131738A1 (en) 2022-04-28
KR102224379B1 (ko) 2021-03-08
EP3523724A1 (en) 2019-08-14
KR20210027527A (ko) 2021-03-10
EP3523724B1 (en) 2023-12-06
JP2020506564A (ja) 2020-02-27
US11240093B2 (en) 2022-02-01
US11799711B2 (en) 2023-10-24

Similar Documents

Publication Publication Date Title
CN109997114B (zh) 用于通用互通和可扩展性的服务层资源管理
CN107211232B (zh) 轻量级机器对机器协议与装置管理协议的互工作
CN104838618B (zh) 在无线通信系统中验证访问授权的方法和设备
KR102646526B1 (ko) 기기간 통신 네트워크에서의 자동화된 서비스 등록
CN108141468B (zh) 增强的restful操作
KR102036420B1 (ko) 머신-투-머신 시스템에서의 애플리케이션 관계 관리
US11831727B2 (en) Profile based content and services
US11765586B2 (en) Context aware authorization for data and services in the IoT/M2M service layer
US11936749B2 (en) Cross-domain discovery between service layer systems and web of things systems

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant