M2M系统中重复发送消息的方法和装置与流程

本发明涉及一种机器对机器(m2m)系统。更具体地说，本发明涉及m2m系统中的消息重复发送方法和装置。本发明还涉及一种m2m系统中的消息重发方法及装置。

背景技术：

近年来，机器到机器(m2m)系统的引入变得活跃。m2m通信是指机器之间在没有人为干预的情况下执行的一种通信。m2m可以指机器类型通信(mtc)、物联网(iot)或设备到设备(d2d)。在下面的描述中，为了便于解释，统一使用术语“m2m”，但本发明不限于此。用于m2m通信的终端可以是m2m终端或m2m设备。m2m终端通常可以是在发送少量数据的同时具有低移动性的设备。本文中，m2m终端可以与集中存储和管理机器间通信信息的m2m服务器结合使用。此外，m2m终端可以应用于各种系统，诸如对象跟踪、汽车联动以及电能计量。

同时，关于m2m终端，onem2m标准化组织提供了m2m通信、物对物通信和iot技术的要求，以及架构的技术、应用程序接口(api)规范、安全解决方案以及互操作性。onem2m标准化组织的规范提供了支持诸如智能城市、智能电网、互联汽车、家庭自动化、安全以及健康等多种应用和服务的框架。

技术实现要素：

技术问题

本发明可以提供一种消息重复发送方法和装置。本发明可以提供一种消息重发方法和装置。本发明可以提供一种m2m系统中的消息重复发送方法和装置。本发明可以提供一种通过在m2m系统中新定义消息重复资源来管理消息重复发送的方法和装置。

本发明可以提供一种通过在m2m系统中新定义消息重复发送属性信息来管理消息重复发送的方法和装置。本发明可以提供一种通过在m2m系统中新定义消息重发资源来管理消息重发的方法和装置。本发明可以提供一种通过在m2m系统中新定义消息重发属性信息来管理消息重发的方法和装置。

问题的解决方案

根据本发明实施例，一种消息重复发送方法包括设置用于消息重复发送的属性信息，配置包括设置的属性信息并且应用于消息重复发送的第一资源，以及根据配置的第一资源执行消息重复发送。用于消息重复发送的属性信息至少包括指定消息重复发送的目标资源的信息(targetresource)和指定作为消息重复发送目标的发送值的信息(valueforrepetition)。

另外，在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定请求消息重复发送的发起方的信息(repetitionoriginator)。在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定消息重复发送的操作方法的信息(targetoperation)。

此外，在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定应用于下一个消息重复发送的值的信息(nextforcedvalue)。在根据本发明实施例的消息重复发送方法中，当在第一资源中更新了nextforcedvalue属性信息时，可以使用nextforcedvalue属性指定的值而不是valueforrepetition属性指定的发送值来执行下一个消息重复发送。

另外，在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定执行消息重复发送操作的间隔的信息(intervalrep)。在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定执行重复发送操作的次数的信息(repetitionduration)。

此外，在根据本发明实施例的消息重复发送方法中，用于消息重复发送的属性信息包括指定接收响应消息的方法的信息(responsemode)。在根据本发明实施例的消息重复发送方法中，第一资源可以是重复创建资源(msgrepetition)。在根据本发明实施例的消息重复发送方法中，第一资源可以包括调度资源作为子资源。

另外，在根据本发明的实施例的消息重复发送方法中，第一资源可以包括在作为父资源的消息重复发送列表(msgrepetitionlist)资源下。在根据本发明实施例的消息重复发送方法中，第一资源可以是订阅资源。在根据本发明实施例的消息重复发送方法中，第一资源可以是组资源。在根据本发明实施例的消息重复发送方法中，除了第一资源之外，还可以包括用于管理消息重复发送的第二资源，并且第二资源可以是订阅资源和组资源中的任一者。

此外，根据本发明的实施例，一种消息重复发送方法包括：接收请求消息重复发送的请求消息；响应于该请求消息，配置包括用于消息重复发送的属性信息并且应用于消息重复发送的第一资源；以及根据所配置的第一资源，执行消息重复发送。用于消息重复发送的属性信息至少包括指定消息重复发送的目标资源的信息(targetresource)和指定作为消息重复发送目标的发送值的信息(valueforrepetition)。

根据本发明实施例，消息重发方法包括：设置用于消息重发的属性信息；配置包括所设置的属性信息并且应用于消息重发的第一资源；以及根据所配置的第一资源，执行消息重发。用于消息重发的属性信息至少包括指定执行重发的最大次数的信息(maxnrofretransmission)和指定重发的消息未传递到的成员的信息(membernotdelivered)。

此外，根据本发明的实施例，一种消息重发方法包括检查是否存在未能接收多播发送的失败节点，并且对于失败节点，根据指定执行重发的最大次数的信息(maxnrofretransmission)执行高达最大重发次数的重发。在根据本发明实施例的消息重发方法中，执行到失败节点的消息重发可以是通过单播发送方法重发的。在根据本发明实施例的消息重发方法中，用于消息重发的属性信息可以包括将单播发送方法和mbms发送方法中的至少一种指定为重发方法的信息(retransmissionmode)。

根据本发明的实施例，一种消息重复发送装置包括至少一个或多个处理器和耦接到至少一个或多个处理器的至少一个或多个存储器。可操作地耦接到至少一个或多个存储器并且执行存储在至少一个或多个存储器中的程序指令的至少一个或多个处理器：设置用于消息重复发送的属性信息，配置包括所设置的属性信息并且应用于消息重复发送的第一资源，并且根据所配置的第一资源执行消息重复发送。用于消息重复发送的属性信息至少包括指定消息重复发送的目标资源的信息(targetresource)和指定作为消息重复发送目标的发送值的信息(valueforrepetition)。

根据本发明的实施例，消息重复发送装置包括至少一个或多个处理器以及耦接到至少一个或多个处理器的至少一个或多个存储器。可操作地耦合到至少一个或多个存储器并且执行存储在至少一个或多个存储器中的程序指令的至少一个或多个处理器：接收请求消息重复发送的请求消息，响应于请求消息配置包括用于消息重复发送的属性信息并且应用于消息重复发送的第一资源，并且根据所配置的第一资源执行消息重复发送。用于消息重复发送的属性信息至少包括指定消息重复发送的目标资源的信息(targetresource)和指定作为消息重复发送目标的发送值的信息(valueforrepetition)。

另外，根据本发明的实施例，消息重发装置包括至少一个或多个处理器以及耦接到至少一个或多个处理器的至少一个或多个存储器。可操作地耦合到至少一个或多个存储器并且执行存储在至少一个或多个存储器中的程序指令的至少一个或多个处理器：设置用于消息重发的属性信息，配置包括所设置的属性信息并且应用于消息重发的第一资源，并且根据所配置的第一资源执行消息重发。用于消息重发的属性信息至少包括指定执行重发的最大次数的信息(maxnrofretransmission)和指定未向传递重发消息的成员的信息(membernotdelivered)。

发明的有利效果

根据本发明，可以提供一种用于有效管理消息重复发送的方法和装置。根据本发明，可以提供一种用于有效管理消息重发的方法和装置。根据本发明，可以提供一种在m2m系统中高效管理消息重复发送的方法和装置。

根据本发明，可以提供一种用于在m2m系统中有效管理消息重发的方法和装置。根据本发明，通过在m2m系统中的定期的消息重复发送，可以向新加入危险警告区域的终端提供有用信息。根据本发明，通过m2m消息中的消息重发，可以向存在于危险警告区域中的每个终端提供紧急警告消息。

在本发明中获得的效果不限于上述效果，并且本领域技术人员可以从以下描述中清楚地理解上述未提及的其它效果。

附图说明

图1是示出根据本发明的m2m系统的分层结构的视图。

图2是示出根据本发明的参考点的视图。

图3是示出根据本发明的每个节点的视图。

图4是示出根据本发明的公共服务功能的视图。

图5和图6示出了根据本发明的消息重复发送和/或重发是必要的场景的示例。

图7是用于说明根据本发明的m2m系统中基于使用请求消息和响应消息的信息交换方法的视图。

图8至图10是用于说明实现根据本发明实施例的消息重复发送方法的处理的视图。

图11至图14示出了实现根据本发明实施例的消息重发方法的处理的示例。

图15至图16简单地示出了根据本发明的消息重复发送的示例。

图17是示出根据本发明的装置配置的示例的视图。

图18是示出根据本发明的装置配置的另一示例的视图。

具体实施方式

在下文中，将参考附图详细描述本公开的实施例，本领域技术人员将容易实施附图。然而，本公开可以以许多不同形式实施，并且不限于在此描述的示例性实施例。

在本公开中，术语第一、第二等仅仅用于区分一个组件与另一个组件的目的，并且不限制组件等的顺序或重要性，除非另有特别说明。因此，在本公开的范围内，一个示例性实施例中的第一组件可以被称为另一实施例中的第二组件，并且类似地，一个示例性实施例中的第二组件可以被称为第一组件。

在本公开中，当部件被称为“链接”、“耦接”或“连接”到另一组件时，应当理解，不仅可以包括直接连接关系，而且还可以包括通过中间组件的间接连接关系。此外，当一个组件被称为“包括”或“具有”另一个组件时，可以意味着另一个组件的还包括而不是排除在其中，除非明确地相反描述。

在本公开中，彼此区分的组件意在清楚地示出每个特征。但是，不一定意味着组件是分离的。即，多个组件可以集成到一个硬件或软件单元中，或者单个组件可以分布到多个硬件或软件单元中。因此，除非另有说明，这样的集成或分布式实施例也包括在本公开的范围内。

在本公开中，在各种实施例中描述的组件不一定是必需的组件，并且一些可以是可选的组件。因此，包括在一个实施例中描述的组件的子集的实施例也包括在本公开的范围内。此外，除了在各个实施例中描述的组件之外，还包括其他组件的示例性实施例也包括在本公开的范围中。

在以下对本公开的示例性实施例的描述中，当可能使本公开的主题不清楚时，将省略对本文中并入的已知功能和配置的详细描述。与附图中与本公开的描述无关的部分被省略，并且相似的部分由相似的附图标记表示。

此外，本说明书描述了基于机器到机器(m2m)通信的网络，并且m2m通信网络中的工作可以在管理通信网络的系统中的网络控制和数据发送的处理中执行。

此外，在本说明书中，m2m终端可以是执行m2m通信的终端。然而，考虑到后向兼容性，可以是在无线通信系统中操作的终端。换言之，m2m终端可以指基于m2m通信网络操作的终端，但不限于此。m2m终端可以基于另一无线通信网络操作，并且不限于上述实施例。

此外，m2m终端可以是固定的或者具有移动性。此外，m2m服务器是指用于m2m通信的服务器，并且可以是固定站或移动站。另外，在本说明书中，实体可以是指像m2m设备、m2m网关以及m2m服务器这样的硬件。此外，例如，实体可以用于指m2m系统的分层结构中的软件配置，并且不限于上述实施例。

此外，例如，本发明主要描述了m2m系统，但并不仅应用于此。此外，m2m服务器可以被配置为执行与m2m终端或另一m2m服务器的通信。此外，m2m网关可以是m2m终端和m2m服务器之间的连接点。例如，当m2m终端和m2m服务器具有不同的网络时，m2m终端和m2m服务器可以经由m2m网关彼此连接。在本文中，例如，m2m网关和m2m服务器都可以是m2m终端，并且不限于上述示例性实施例。

图1是示出m2m系统的分层结构的视图。参照图1，m2m系统的分层结构可以包括应用层110、公共服务层120以及网络服务层130。在本文中，应用层110可以是基于特定应用进行操作的层。例如，应用可以是车队跟踪应用、远程血糖监测应用、电能计量应用或控制应用。换言之，应用层可以是用于特定应用的层。在本文中，基于应用层操作的实体可以是应用实体(ae)。

公共服务层120可以是用于公共服务功能(csf)的层。例如，公共服务层120可以是被配置为提供诸如数据管理、设备管理、m2m服务订阅管理以及位置服务的公共服务的层。例如，基于公共服务层120操作的实体可以是公共服务实体(cse)。网络服务层130可以向公共服务层120提供诸如设备管理、位置服务以及设备触发的服务。在本文中，基于网络服务层130操作的实体可以是网络服务实体(nse)。

图2是示出m2m系统结构的视图。参照图2，m2m系统结构可以区分为字段域和基础设施域。在本文中，在每个域中，每个实体可以被配置为通过参考点执行通信。例如，参考点可以表示每个实体之间的通信流。在本文中，参照图2，可以设置ae与cse之间的参考点mca、不同cse之间的参考点mcc以及cse与nse之间的mcn参考点。

图3是示出m2m系统结构的设置的视图。参照图3，特定m2m服务提供商的基础设施域可以提供特定基础设施节点(in)310。在本文中，in的cse可以被配置为基于ae和另一基础设施节点的参考点mca来执行通信。特别地，可以为每个m2m服务提供商设置一个in。换言之，in可以是被配置为基于基础设施结构与另一基础设施的m2m终端执行通信的节点。此外，例如，在概念上，节点可以是逻辑实体或软件配置。

此外，应用专用节点(adn)320可以是包括至少一个ae但不包括cse的节点。在本文中，可以在字段域中设置adn。换言之，adn可以是ae的专用节点。例如，adn可以是在硬件中设置在m2m终端中的节点。此外，应用服务节点(asn)330可以是包括一个cse和至少一个ae的节点。可以在字段域中设置asn。换言之，asn可以是包括ae和cse的节点。在本文中，asn可以是连接到in的节点。例如，asn可以是在硬件中设置在m2m终端中的节点。

此外，中间节点(mn)340可以是包括cse并且包括零个以上ae的节点。在本文中，mn可以被设置在中字段域中。mn可以基于参考点连接到另一个mn或in。此外，例如，可以在硬件中在m2m网关中设置mn。此外，作为示例，非m2m终端节点350(非m2m设备节点nodn)是不包括m2m实体的节点。该非m2m终端节点350可以是与m2m系统一起执行管理或协作的节点。

图4是示出公共服务功能的视图。参照图4，可以提供公共服务功能。例如，公共服务功能可以提供应用和服务层管理、通信管理和传递处理、数据管理和存储库、设备管理、发现、组管理、位置、网络服务暴露/服务执行和触发、注册、安全、服务计费和记帐、服务会话管理以及订阅/通知中的至少任一个功能。在本文中，m2m终端可以被配置为基于公共服务功能来操作。此外，公共服务功能在其它示例性实施例中也是可能的，并且不限于上述示例性实施例。

此外，例如，在m2m系统中可以包括m2m平台、m2m网关、m2m设备以及应用实体(ae)中的至少任一者。例如，in可以用作m2m平台，mn可以用作m2m网关。此外，asn或adn可以是m2m设备，并且可以基于上述描述来操作。此外，如上所述，例如，cse用作m2m系统的公共功能元件，并且可以执行公共功能。在本文中，如上所述，为了实现该功能，cse可以包括在用作m2m平台、m2m网关以及m2m设备的asn中。此外，例如，ae可以包括在m2m平台、m2m网关、asn以及and中的任一者中。此外，例如，ae可以被单独使用并且不限于上述实施例。

在本文中，例如，托管的公共服务实体(h-cse)可以是持有资源或属性的实体，并且注册器公共服务实体(r-cse)可以是在其中注册有终端(或m2m终端)的cse。在本文中，例如，终端可以是adn、asn以及mn中的至少一者。此外，例如，r-cse和h-cse可以是asn、mn以及in中的至少一者或多者。

例如，终端可以被配置为通过r-cse从h-cse获取资源。同时，可以基于在m2m系统中操作的对象来表示资源。例如，可以基于特定服务的终端操作信息来定义资源，并且可以基于创建/检索/更新/删除(crud)来表示资源。对于更具体的示例，终端(或ae)可以通过r-cse从h-cse获得资源和目标资源的属性信息。在本文中，如上所述，h-cse可以向ae提供用于特定服务的资源及其属性信息。例如，h-cse可以是用于特定服务的资源服务器。例如，资源服务器可以是车辆驾驶服务器或车辆管理服务器。换言之，终端可以被配置为基于资源从服务器获取针对特定服务的信息，并且基于该信息操作。同时，例如，m2m系统中的cse可以包括收发机、处理器和存储器。基于此，cse可以被配置为向其它节点发送数据包和从其它节点接收数据包以处理该数据包。稍后将描述装置配置。

此外，例如，资源可以被配置为通过容器存储相关信息并且与另一实体共享数据。在本文中，内容实例(contentinstance)可以是子资源。此外，例如，每个资源的属性信息可以是该资源的特定描述。在本文中，资源属性信息可以被配置为存储资源的属性数据。基于上述，终端(ae)可以被配置为通过r-cse从h-cse获得特定资源。在本文中，资源可以包括属性信息作为目标属性信息。终端可以被配置为基于所获得的资源和属性信息来执行针对特定服务的操作。

图5和图6示出了根据本发明的消息重复发送和/或重发是必要的场景的示例。特别地，3gpp多媒体广播多播服务(mbms)通常已知指定包括服务通知、搜索以及消息传递的各种多播功能。此外，根据onem2mts-0026文档，规定了支持与包括mbms的3gpp的互通功能。因此，在m2m环境中，还存在将相同内容重复发送或重发到用户终端或成员频繁变更的用户组的场景。

首先，例如，如图5所示，消息发送节点500可以被配置为运行定期地向位于道路上的特定区域510(在下文中，称为“交通通信区域”)中的车辆组发送交通信息的服务。因此，当新用户组520出现在交通通信区域510内时，消息发送节点500也应该能够不断地提供相同的交通信息。与此相关，在m2m系统中需要新的规定来向新用户组520发送消息。例如，首先可以执行针对每个用户终端的单播发送，然后可以执行针对所有用户终端的多播发送。另外，作为替代，例如，在创建或生成并发送临时多播组之后，可以通过将临时多播组并入到原始多播组中来执行多播发送。在下文中，本发明将详细描述在类似图5的场景中在m2m系统中的高效的消息重复发送方法和/或消息重发方法。

第二，例如，如图6所示，消息发送节点600可以被配置为运行向位于发生森林火灾的特定区域(在下文中，称为“危险警告区域”)中的所有用户终端发送危险警告消息的服务。因此，有必要重复且定期地向存在于紧急危险警告区域内的所有用户终端提供相同的危险警告消息。在本文中，当存在于紧急危险警告区域内的特定用户终端610没有接收到危险警告消息时，必须重发危险警告消息，使得特定用户终端610可以接收到危险警告消息(620)。此外，根据危险情况的发展，还必须更新危险警告消息，并且再次重复发送更新的警告消息。因此，必须不断激活作为通信区域的紧急危险警告区域。在下文中，本发明将详细描述在类似图6的场景中在m2m系统中的高效的消息重复发送方法和/或消息重发方法。

此外，与图5和图6的上述场景一样，当需要消息重复发送时，需要提供方式以减少消息发送节点500和600与用户终端之间的消息重复发送所引起的开销。换言之，还需要一种用于减少由在m2m系统中具有相互通信的两个实体之间的消息重复引起的开销的方法。

图7是用于说明在m2m系统中基于使用请求消息711和响应消息721的信息交换方法的视图。通过参考点之间的消息交换来实现包括cse和ae的消息交换处理。例如，请求消息和响应消息可以应用于ae和cse(mca参考点)之间的通信或cse(mcc参考点)之间的通信。此外，通信可以根据请求消息的内容由ae或由cse公开。公开请求消息的实体特别地被称为“发起方”710。另一方面，接收请求消息并且发送相应响应消息的实体被特定称为“接收器”720。

因此，在下文中，根据本发明的用于消息重复发送和重发的方法和装置将指定请求消息711和响应消息721的使用作为基本处理。此外，由于在各种实施例中可以配置用于消息重复发送和消息重发的方法和装置，因此将根据每个实施例分别地详细描述该方法和装置。

1.使用消息重复发送资源的消息重复发送的实施例

图8至图10是用于说明实现根据本发明实施例的消息重复发送方法的处理的视图。特别地，本发明的一个实施例具有重新指定消息重复资源(例如<msgrepetition>)和该资源的属性信息的特点。

图8示出了根据本发明实施例的消息重复资源的示例。对于消息重复发送，可以创建单独的<msgrepetition>资源810。在本文中，为了有效利用<msgrepetition>资源810，可以在<msgrepetition>资源的位置上方创建<msgrepetitionitionlist>资源800。另一方面，也可以在常规的<node>资源下创建<msgrepetition>资源810，而不是在特定的<msgreportitionlist>资源800下创建<msgrepetition>资源810。然而，在这种情况下，实体处理器具有连续地检查<msgrepetition>资源810是否存在的负担。

与此相关，<msgrepetition>资源810可以配置有包括至少一个或多个消息重复(msgrepetition)属性的子资源811至818。特别地，为了高效地执行消息重复发送，需要定义消息的属性。例如，可以通过属性来减少消息重复发送的开销。

表1公开了包括在<msgrepetition>资源810中的消息重复(msgrepetition)属性的示例。

表1

具体地，“targetresource”属性811是指定需要消息重复发送的目标资源的信息。例如，该信息可以表示交通信息、危险警告信息等，并且可以由“contentinstance”表示。

此外，“intervalrep”属性812是指定执行消息重复发送操作的间隔的信息。例如，可以设置像每一分钟、每十分钟、每一小时这样的间隔时间。因此，可以根据重复发送服务的类型而不同地确定“intervalrep”属性812。例如，在如图6的场景中调用紧急情况的危险警告消息的情况下，较短的间隔是优选的。

此外，“repetitionduration”属性813是指定执行消息重复发送操作的次数的信息。例如，可以将该次数设置为一次、确定的有限次数、无限重复等。因此，当完整执行了由“repetitionduration”属性813指定的次数的重复时，可以删除<msgrepetition>资源。

此外，“valueforrepetition”属性814是指定消息重复发送的目标发送值的信息。例如，像特定的温度和特定的空气污染水平，它意味着要从重复发送中获得特定的信息。与此相关，“valueforrepetition”属性814可以通过与上述“targetresource”属性811一起应用来用于定义重复发送的目标资源(例如，目标应用服务)和目标重复发送值。特别地，这样的属性在减少消息重复发送的开销方面是有效的，因为它们澄清了重复发送消息的目标。

此外，“responsemode”属性815是指定接收响应消息的方法的信息。例如，可以指定配置为诸如立即、每10分钟以及累积响应的响应消息的方法。此外，“nextforcedvalue”属性816是指定在下一个消息重复发送中应用的值的信息。在本文中，将“nextforcedvalue”属性816与上述“valueforrepetition”属性814进行对比。换言之，这意味着，当由“valueforrepetition”属性814执行重复发送时，如果“nextforcedvalue”属性816被更新，则应使用由“nextforcedvalue”属性指定的值、而不是“valueforrepetition”属性814指定的值执行下一个消息重复发送。

此外，“repetitionoriginator”属性817是指定请求消息重复发送的发送节点(发起方)的信息。此外，“lastresponse”属性818包括关于被发送到发送节点(发起方)的最后响应的信息。此外，“targetoperation”属性是指定消息重复发送的操作方法的信息。例如，这可以将操作区分为消息创建操作(“创建(create)”)或消息更新操作(“更新(update)”)。在本文中，消息创建操作(“创建”)是指重复地生成相同的消息，并且消息更新操作(“更新”)是指在重复发送期间发送更新的消息。

此外，尽管在表1中未公开，但可以设置“repetitionmode”属性。“repetitionmode”属性可以是设置执行重复发送的模式(即，例如，单播模式或多播模式或其他发送模式中的任一种模式)的信息，并且指定发送模式的混合使用(例如，“多播”后接“单播”)。

图9示出了根据本发明实施例的消息重复发送的处理的示例。特别地，图9是示出当请求消息重复属性信息时in-cse920的详细响应处理的一个示例。换言之，当发起方910向in-cse920请求消息重复发送时，in-cse920的详细响应处理如下。首先，例如，发起方910可以被配置为通过请求消息请求in-cse920在一天内每10分钟在容器‘y’下创建信息‘x’。在本文中，请求消息可以包括在上述表1中公开的消息重复(msgrepetition)属性中的至少一个或多个。

当接收到请求消息时，首先，in-cse920可以被配置为在<msgrepetitionlist>下生成上述<msgrepetition>资源(921)。此外，in-cse920可以配置<msgrepetition>资源的子资源(922)。例如，如上面图8所示，可以使用包括在请求消息中的消息重复属性来配置子资源。

接下来，in-cse920检查内部处理器的消息重复发送(923)。例如，in-cse920可以被配置为基于所创建的<msgrepetition>资源和其中设置了消息重复属性的子资源来确定是否执行消息重复发送。换言之，基于设置的消息重复属性，可以至少确定消息重复发送的目标、间隔、持续时间以及值。此外，当存在调度的消息重复时，in-cse920可以被配置为执行响应操作。

在本文中，当发起方910希望接收新的重复发送值时，发起方910可以被配置为更新上述nextforcedvalue属性。接下来，in-cse920使用由nextforcedvalue属性指定的值执行下一个消息重复发送(924)。此外，in-cse920可以被配置为基于上述responsemode属性来设置响应策略，创建用于向发起方910发送响应消息的会话，并且开始发送响应消息(925)。接下来，当基于上述repetitionduration属性确认了消息重复持续时间完成时，in-cse920可以被配置为删除<msgrepetition>资源并且完成消息重复发送(926)。

图10示出了根据本发明实施例的消息重复发送的另一处理的示例。特别地，图10是示出在重复发送处理中如何使用消息重复属性的特定示例。ae#11010发送请求消息重复发送的请求消息(001)。在本文中，例如，对于创建<contentinstance>的<container-x>，可以每隔一段时间‘t’指定一个重复发送属性，直到日期‘d’为止。

in-cse1020验证ae#11010的可靠性。例如，检查<container-x>和ae#11010的访问控制策略。在本文中，当没有错误时，in-cse1020可以被配置为生成<msgrepetitionlist>下的<msgrepetition>以及所请求的信息(002)。此外，in-cse1020可以被配置为发送<msgrepetition>的成功创建作为对ae#11010的请求消息的响应(003)。例如，这样的响应可以是ack消息。

在本文中，另一个ae#21030可以被配置为请求对in-cse1020的<container-x>的订阅(004)。在时间‘t’之后，in-cse1020检查与<container-x>相关的<msgrepetition>的存在，并且为<container-x>创建<contentinstance>(005)。在本文中，例如，可以创建具有值‘y’的<contentinstance>。

在本文中，ae#21030接收在<container-x>中创建新<contentinstance>的通知(006)。此外，当ae#11010希望请求与由先前配置的valueforreputation属性指定的值(‘y’)不同的值(例如‘z’)时，ae#11010可以被配置为发送请求更新<msgrepetition>资源的消息重复属性中的nextforcedvalue的请求消息(007)。

in-cse1020更新nextforcedvalue属性。接下来，在时间‘t’之后，in-cse1020检查与<container-x>相关的<msgrepetition>资源的存在，并且为<container-x>创建(create)<contentinstance>(008)。在本文中，可以生成具有更新值‘z’的<contentinstance>。接下来，in-cse1020可以在内部移除nextforcedvalue属性。这旨在为再次接收nextforcedvalue做准备。

最后，ae#21030接收到创建具有<container-x>‘z’值的新<contentinstance>的通知(009)。因此，通过应用图9和图10的消息重复发送处理，可以解决在图5和图6的上述场景中所需要的消息重复发送问题。例如，当交通信息应用服务运营商(例如，ae)向通信基站(例如，in-cse)发送包括消息重复属性信息的请求消息时，通信基站(例如，in-cse)变得能够基于设置的消息重复属性信息向交通通信区域内的用户终端重复发送交通信息消息。

2.使用发布-订阅资源消息重复发送的实施例

在下文中，基于本发明的另一实施例，将描述执行消息重复发送的处理。图15至图16简单地示出了根据本发明的消息重复发送的示例。例如，描述了onem2m系统作为示例。然而，本发明不限于onem2m系统。

在本发明之前开发的onem2m系统中，对于消息重复传递，应用实体(ae)必须不断地发送对注册资源的传递请求。这对ae来说可能是一个很大的开销负担。为了减少ae所需的负担，本发明提出使用重复发送资源和重复发送属性信息。

例如，如图15所示，本发明提出了ae1510在消息重复发送资源内设置针对特定资源a的重复发送的属性信息(1511)，并且将该属性信息以请求消息形式传递给托管的cse1520的处理。例如，消息重复发送资源可以是<request>资源和/或<schedule>资源。因此，接收到请求消息的托管cse1520变得能够响应于请求消息而重复地将资源a传递到另一个cse1530。因此，该处理可以通过最小化ae1510的重复传递请求来最小化ae的开销负担。

此外，在本发明之前开发的onem2m系统采用基于发布-订阅的消息传递方法。因此，在本发明之前的onem2m系统中，例如，当需要特定资源(例如，请求颗粒物质(pm)水平通知的资源)的恒定通知时，必须创建多个相同的订阅条件。因此，可以接收多个对应通知，但这种方法效率低。为了改善ae所需的低效率，本发明提出使用重复发送资源(例如<subscription>资源)和重复发送属性信息。

例如，如图16所示，请求对资源a的重复订阅的cse21620可以被配置为发送包括<subscription>资源内的重复属性信息的订阅请求消息1621。接收到订阅请求消息1621的cse11610变得能够基于设置的重复属性信息重复地执行针对资源a的通知。

在下文中，将详细描述支持以上图15和图16的基本处理的详细消息重复发送资源和重复发送属性信息。与此相关，订阅资源可以包括定义发送对应通知的时间和方法的通知策略。在本文中，重复发送可以被设置为通知策略之一。例如，作为配置消息重复发送资源的方法，可以将重复属性信息添加到消息重复发送资源中。此外，订户可以配置在消息重复发送资源内接收重复发送通知的方法。此外，源创建者可以在消息重复发送资源内定义强制消息重复的资源属性。

通常，订户可以请求特定资源的通知作为订户模式。例如，针对特定资源的警报或警告消息请求可以是一个示例。然而，通常，由于订户不确信接收到了对应的消息通知，因此订户可能希望重复接收消息通知。在本发明中，这种情况被称为面向订户的消息重复请求。此外，例如，当源创建者是对应于图5和图6的上述场景的应急管理中心或交通管理中心时，源创建者本身可能希望强制消息重复发送。在本发明中，这种情况被称为面向创建者的消息重复请求。

在下文中，分别给出了面向订户的消息重复请求方法和面向创建者的消息重复请求方法的具体实现方法。

(1)面向订户的消息重复请求

本发明提出了分别使用<subscription>资源和<schedule>资源作为面向订户的消息重复请求方法。

首先，根据本发明，<subscription>资源的特征可以总结如下。<subscription>资源包括要订阅的资源的订阅信息。例如，对于特定资源的订阅，可以向m2m架构实体请求<subscription>资源。换言之，<subscription>资源是指对特定资源的订阅。为了完成订阅，需要将<subscription>资源创建为要订阅的资源的子资源。相应地，子<subscription>资源应该包括准确的订阅范围和关于要通知的对象的信息。例如，当<subscription>资源作为父<container>资源下的子资源存在时，其应被配置为满足父<container>资源中描述的通知事件准则的子<subscription>资源。此外，例如，当要订阅的父资源被删除时，子<subscription>资源也可以被删除。

此外，通常情况下，当发起方具有<subscription>资源的检索(retrieve)权限时，发起方应该能够创建<subscription>资源类型的资源。换言之，创建<subscription>资源的发起者可以是资源订户。此外，<subscription>资源可以被配置为拒绝和阻止用以更改资源或资源属性的“update”请求的“update”。此外，<subscription>资源可以包括指定要通知的目标、时间以及方法的通知策略。此外，当<subscription>资源被删除时，如果存在由订户指示的目标，那么应该可以向该目标发送通知请求。在本文中，要通知的目标可以由subscriberuri属性指定。

表2公开了在面向订户的消息重复请求时<subscription>资源内的属性信息的示例。

表2

在本文中，为了配置消息重复策略，订户可以在<subscription>资源内配备有附加属性信息。

当对应的值为0或1时，“notirepetition”属性可以以预定的方式(例如，不通知或仅通知一次)执行响应通知。另一方面，当“notirepetition”属性值大于1时，响应通知可以执行与该值相同的次数。例如，当对应的值被指定为3时，响应通知可以重复三次。

此外，“notiinterval”属性是指定重复通知间隔的信息。“startrepition”属性是指定重复发送的开始时间的信息。此外，“endreportation”属性是指定重复发送的结束时间的信息。与此相关，在表2的描述部分中提供了有关属性的进一步详细公开。

因此，通过在<subscription>资源中设置附加属性信息，可以实现根据本发明的消息重复发送。这将是在保持与现有m2m系统的兼容性的同时实现消息重复发送处理的示例。

接下来，提出使用m2m系统的<schedule>资源作为根据本发明的在面向订户的消息重复请求时实现消息重复发送的另一种方法。<schedule>资源可以包括调度信息。此外，<schedule>资源可以是上述重复创建资源<megrepetition>的子资源。此外，<schedule>资源可以是订阅资源<subscription>的子资源。

表3公开了在面向订户的消息重复请求时<schedule>资源内的属性信息的示例。

表3

在本文中，为了配置消息重复策略，订户可以在<schedule>资源内配备附加属性信息。“repetitionpolicy”属性是指定如何执行重复通知的信息。例如，当对应的值为0时，可以发送所有调度的通知，而不考虑通知顺序。另一方面，当对应的值为1时，前一个通知后面留下的通知可以不被发送、而是被忽略。

此外，“scheduleelement”属性可以包括构成重复通知调度时间的七个字段。例如，这七个字段可以由秒、分钟、小时、月中的某天、月、周中的某天和年组成。此外，可以选择性地进一步添加“通知标识符”属性以区分重复发送的通知。例如，为了区分重复发送的通知，“通知标识符”属性值可以实现为增加1(例如，noti-00001、noti-00002、...)。

与此相关，关于属性的进一步详细披露见表3的描述部分。因此，通过在<schedule>资源中设置附加属性信息，可以实现根据本发明的消息重复发送。这将是在保持与现有m2m系统的兼容性的同时实现消息重复发送处理的示例。

(2)面向创建者的消息重复请求

本发明提出使用<resourcename>资源作为面向创建者的消息重复请求方法。创建者可以指的是发布者。创建源资源(例如，容器资源)的创建者可以配置所创建的源资源的重复发送策略。

表4公开了在面向创建者的消息重复请求时<resourcename>资源内的属性信息的示例。

表4

特别地，为了配置消息重复策略，源资源创建者可以在<resourcename>资源中包括消息重复发送策略。“notirepetitionmode”属性是指定重复发送模式的信息。例如，当对应值为1时，可以以预定的通常方式(例如，一次通知)执行响应通知。另一方面，当对应的值大于1时，响应通知可以重复发送与设定的数量一样多的次数。例如，当对应的值被设置为3时，重复发送可以执行三次。

此外，“notiinterval”属性是指定执行消息的重复通知的间隔的信息。例如，可以将间隔的信息设置为每10分钟、每小时等。当特定订户为源资源创建订阅资源时，创建者可以被配置为通过使用属性来设置消息重复发送策略。特别地，当在订户的<subscription>资源中设置了如上述表2中的重复发送属性时，如果创建者接收到订户的重复发送属性请求，则可以发送接收消息(例如，ack)。另一方面，当订户的<subscription>资源中的重复发送属性信息违反由创建者设置的重复发送策略时，可以发送拒绝订户的重复发送属性请求的消息(例如，nack)。与此相关，如上所述，当消息重复发送策略在创建者和订户之间不同时，可能需要准备用于解决m2m系统中的差异的仲裁策略。例如，可以根据场景设置在创建者和订户之间优选哪个消息重复发送策略，并且这样的消息重复发送策略可以用作仲裁策略。

此外，表5公开了在面向创建者的消息重复请求时<resourcename>资源内的其他属性信息的示例。

表5

“notirepetition”属性是指定强制重复发送的信息。例如，无论订户或请求者的重复订阅请求或重复发送请求如何，源创建者可以被配置为以强制方式向所有相关订户和请求者重复发送特定资源。例如，当对应的源资源是图6中的上述场景的紧急资源时，可以执行强制重复发送。

与此相关，需要单独设置重复发送的次数。例如，可以利用表4中的上述“notirepetitionmode”属性。此外，“notiinterval”属性是指定执行消息的重复通知的间隔的信息。例如，可以设置为每10分钟、每小时等。

因此，通过在<resourcename>资源中设置附加属性信息，可以实现根据本发明的面向创建者的消息重复发送。这将是在保持与现有m2m系统的兼容性的同时实现消息重复发送处理的示例。

3.使用组资源进行消息重复发送的实施例

在下文中，根据本发明的实施例，将描述使用组资源和对应的资源属性信息的消息重复发送方法。例如，描述了onem2m系统作为示例。然而，本发明不限于onem2m系统。

在本发明之前开发的onem2m系统能够使用<group>资源向同一组的多个用户同时发送请求消息或响应消息。然而，<group>资源在根据本发明实现消息重复发送时具有限制。因此，提出通过在<group>资源内新定义用于重复发送的属性信息来实现根据本发明的消息重复发送处理。

表6公开了为了实现根据本发明的消息重复发送处理而在<group>资源内额外设置的用于重复发送的属性信息的示例。

表6

“startmulticastrepetation”属性是指定多播重复的开始时间的信息。“endmulticastrepetation”属性是指定多播重复的结束时间的信息。“maxnrofrepetition”属性是指定最大重复发送次数的信息。“currentnrofrepetition”属性是指定执行重复发送次数的信息。“currentsessionid”属性是指定当前消息的标识的信息。

此外，“repetitionmode”属性是指定将哪种发送模式应用于新加入组的成员(例如，用户终端)的信息。例如，可以选择单播发送、临时多播以及无动作中的任何一种。特别地，“repetitionmode”属性可以用作属性信息，以确定在图5的上述场景中如何对新加入交通通信区域的车辆执行消息发送。此外，“repetitionmode”属性可以用作属性信息，以确定在图6的上述场景中发生危险情况的紧急危险警告区域中如何执行对用户终端的消息发送。

此外，“membernewlyjoined”属性是设置作为组的新成员(例如，用户终端)但尚未接收到消息的用户列表的信息。“membersnotread”属性是设置作为组的新成员(例如，用户终端)但尚未读取发送的消息的用户列表的信息。特别地，“membernewlyjoined”属性和“membersnotread”属性可以用作属性信息，以识别在图5的上述场景中新加入交通通信区域的车辆，并且识别车辆当中的尚未接收到消息的用户。此外，“membernewlyjoined”属性和“membersnotread”属性可以用作属性信息，以识别在图6的上述场景中新加入发生危险情况的紧急危险警告区域的用户终端，并且识别用户终端当中尚未接收到消息的用户终端。

与此相关，为了实现根据本发明的消息重复发送处理，还可以生成<multicastrepetition>资源作为<group>资源下的子资源，并且定义用于执行多播重复发送的属性。此外，为了实现根据本发明的消息重复发送处理，可以生成<fanoutpoint>资源作为<group>资源下的子资源，并且在执行多播重复发送时，将每个<fanoutpoint>资源属性值更新为相同的值。

在本文中，为新加入多播组的新成员实现多播重复发送的方法如下。首先，通过检查“repetitionmode”属性来确认将单播和多播之间的哪种发送模式应用于新成员。当单播发送被设置时，托管cse的组首先对新加入的成员执行单播消息发送，并在单播发送后从多播组中移除新成员。另一方面，当多播发送被设置时，托管cse的组生成由新加入的成员组成的新的子多播组，并对新创建的子多播组执行多播(例如<fanoutpoint>资源更新)。在多播发送之后，从多播组中移除新的子多播组。

表7公开了在<schedule>资源内额外设置的用于重复发送的属性信息的示例，以实现根据本发明的消息重复发送处理。

表7

“startmulticastschedule”属性是指定多播重复的开始时间的信息。“endmulticastschedule”属性是指定多播重复的结束时间的信息。“maxnrofrepetition”属性是指定最大重复发送次数的信息。“currentnrofrepetition”属性是指定执行重复发送次数的信息。“currentsessionid”属性是指定当前消息的标识的信息。

例如，作为<node>资源的子资源，<schedule>资源在对应节点指定时间间隔时是可用的，在该时间间隔可以通过网络进行通信。因此，通过将本发明的消息重复发送属性信息添加到<schedule>资源，可以在通信可能的时刻实现消息重复。

4.使用资源和属性信息进行消息重发的实施例

在下文中，根据本发明，将描述使用m2m资源和属性信息的消息重发方法。如在上面的图5和图6的场景中所描述的，可能存在应该被发送到特定区域中的所有用户终端的信息。例如，这类信息可以是交通事故信息、森林火灾警告信息等。特别地，由于这样的警告信息应该被发送到对应区域中的所有用户终端，当在特定用户终端或所有用户终端中发生发送失败时，需要重发功能。此外，由于最近的车载终端经常因为行驶速度过快而无法接收到主警告信息，因此也需要对此进行解决。相应地，当多播发送失败时，需要实现重发对应的失败消息的处理。

表8公开了用于重复发送的属性信息的示例，该属性信息额外设置在<group>资源内，以便实现根据本发明的消息重发处理。

表8

“maxnrofretransmission”属性是指定执行重发的最大次数的信息。“currentnrofretransmission”属性是指定当前执行重发次数的信息。例如，“currentnrofretransmission”属性值不能大于执行重发的最大次数。

此外，“membernotdelivered”属性是指定不将重发消息传递到的成员的信息。“membersnotread”属性是指定已接收到发送的消息但尚未读取该消息的成员的信息。“retransmissionmode”属性是指定重发模式的信息。例如，可以选择单播发送和mbms发送(例如，3gpp)中的一个。“maxretransmissiontime”属性是指定重发时间限制的信息。“startwindowretransmission”属性是指定要执行重发的时间窗口间隔的信息。

特别地，“membernotdelivered”属性和“membersnotread”属性可以用作属性信息，以识别在图5的上述场景中新加入交通通信区域的车辆，并且识别车辆中尚未接收到消息的用户。此外，特别地，“membernotdelivered”属性和“membersnotread”属性可以用作属性信息，以识别在图6的上述场景中新加入发生危险情况的紧急危险警告区域的用户终端，并且识别用户终端中尚未接收到消息的用户终端。此外，“retransmissionmode”属性可以用于确定应用于需要重发的用户终端的通信模式。

表9公开了根据本发明在<localmulticastgroup>资源内额外设置以实现消息重发处理的用于重发的属性信息的示例。

表9

存在于现有<localmulticastgroup>资源中的“tmgi”属性是表示本地多播组是否支持3gpp中定义的mbms服务的信息。例如，由于m2m系统具有与3gppmbms的互通功能，因此属性是用于请求和识别这一点的信息。换言之，例如，当“tmgi＝1”时，可以定义为支持mbms。另一方面，当“tmgi＝0”时，可以定义为不支持mbms。此外，“retransmissiontmgi”属性是表示重发中的tmgi的信息。

图11至图14示出了实现根据本发明实施例的消息重发方法的处理的示例。具体地，图11、图12以及图14示出了创建mbms组并且使用对应mbms组的消息重发方法。另一方面，图13示出了不使用mbms组、而是使用多播模式的消息重发方法。

图11示出了根据本发明实施例的创建mbms组的处理的示例。在本文中，可以在m2m系统中配置由运营商提供的mbms服务区域信息。此外，在m2m系统中，可以预先设置装置的外部组标识符。

首先，in-ae1150向组托管cse1140发送<group>资源创建请求。接下来，组托管cse1140检查两个或更多个成员托管cse1110的<remotecse>资源的多播容量特征是否由mbms值组成并且是否具有相同的外部组标识符(externalgroupid)。接下来，组托管cse1140向in-ae/cse1150发送响应。

接下来，组托管cse1140向scef1130发送tmgi分配的请求。该请求应包括3gppts29.122[5]中规定的以下信息。

-应该使用httppost方法。

-uri应被设置为{apiroot}/3gpp-group-message-delivery-mb2/v1/{scsasid}/tmgi-allocation。{apiroot}和{scsasid}段基于服务提供商和mno策略。

-请求有效载荷应包括3gppts29.122[5]中规定的tmgiallocation数据结构，并且应包括以下属性。换言之，应该将externalgroupid设置为成员托管cse1110的externalgroupid。

此外，可以根据准确性策略将mbmslocarea设置为成员托管cse1110的位置信息。此外，supportedfeatures应设置为字符串值‘0’，该值表示不支持通过网站或通知测试事件进行通知。

然而，当托管cse(即，in-cse1140)希望发送tmgi分配请求时，可以存在scef不可达的情况。特别地，in-cse1140可以不获得在基本3gpp网络中分配的tmgi。因此，in-cse1140可以不能对对应的组使用多播功能。特别地，in-cse1140可以使用单播功能来处理对组的请求。

接下来，基本3gpp网络可以根据3gppts23.682[2]中定义的步骤来处理tmgi分配请求。在本文中，scef1130向组托管cse1140发送分配tmgi响应。该响应包括3gppts29.122[5]中规定的以下信息。

-201已创建响应代码

-在http位置报头中的scef中创建的cpc(通信模式配置)订阅资源的uri，uri以{apiroot}/3gpp-group-message-delivery-mb2/v1/{scsasid}/tmgi-allocation/{tmgi}的形式返回。{apiroot}和{scsasid}段可以基于服务提供商和mno策略配置。在本文中，{tmgi}段可以由scef配置。

-响应有效载荷可以包括3gppts29.122[5]中指定的tmgiallocation数据结构，该数据结构包括存在于请求中的属性，并且可以包括以下附加属性。换言之，可以配置针对scef创建的{apiroot}/3gpp-group-message-delivery-mb2/v1/{scsasid}/tmgi-allocation/{tmgi}资源的链接。另外，tmgi由特定mbms承载服务的id配置，并且tmgiexpiration由将tmgi视为过期的绝对时间配置。

接下来，组托管cse1140将tmgi和tmgiexpiration存储在本地多播组信息中，并且通过包括必要属性的单播向成员托管cse1110发送<localmulticastgroup>创建请求。在多播的情况下，类型是3gpp_mbms_group，并且请求包括tmgi和responsetimewindow。

图12示出了通过使用通过图11的上述处理生成的mbms组来发送组消息的处理的示例。首先，可以通过图12的步骤s1至步骤s4进行有效的tmgi分配。

接下来，in-ae/cse1250向组托管cse1240发送请求，该请求包括用于访问成员资源的组访问标识符。例如，在多播的情况下，类型是3gpp_mbms_group，并且组托管cse1240针对作为<node>资源的每个成员托管cse1210，检查作为子资源的现有<schedule>资源。当不存在现有<schedule>资源的时间交集时，组托管cse1240在处理结束后向in-ae/cse1250发送错误响应。另一方面，当存在时间交集时，当操作执行时间或请求到期时间戳包括在请求中时，组托管cse1240检查操作执行时间和请求到期时间戳是否在交集范围内。否则，在处理结束之后，组托管cse1240向in-ae/cse1250发送错误响应。

接下来，在通过向scef1230发送组消息传递请求来激活mbms承载之后，组托管cse1240应该从时间交集的下一开始时间为mbms成员提供mbms通信网络资源。该请求可以包括3gppts29.122[5]中指定的信息。接下来，mbms承载激活处理可以由基本3gpp网络根据3gppts23.682[2]中定义的步骤来处理。此外，scef1230向组托管cse1240发送组消息响应。该响应可以包括3gppts29.122[5]中指定的信息。

基本3gpp网络可以基于3gppts23.682[2]中定义的处理来处理由mbms处理进行的组消息传递。接下来，scef1230向组托管cse1240发送组消息传递通知。通知消息可以包括在3gppts29.122[5]中规定的信息。

接下来，在接收到组消息传递通知之后，组托管cse(in-cse)1240可以发送具有特定响应代码(例如204无内容)的响应。接下来，成员托管cse1210可以被配置为在响应时间窗口(timewindow)范围内发送响应消息。在本文中，组托管cse1240从成员托管cse1210接收响应消息，直到responsetimewindow到期为止，并且组托管cse1240将收集的组成员响应返回给in-ae/cse1250。

图13示出了根据本发明实施例的消息重发处理的示例。具体地，图13涉及使用多播的消息重发处理。

当多播消息传递失败时，组托管cse1230通过单播向失败节点重发消息。换言之，组托管cse1230从membernotdelivered属性来识别成员当中的传递失败的成员，并且向该成员发送单播消息传递。当单播传递成功时，组托管cse1230删除membernotdelivered。在指定数量的重发之后，组托管cse1230认为失败节点不再可用，并且从<group>资源中移除对应的成员。

此外，当仍然存在未成功接收重发消息的失败节点成员时，ae1250可以重复执行请求，直到达到最大重发次数(maxnrofretransmission)。另一方面，当给定的最大重发次数(maxnrofretransmission)用完时，组托管cse1230可以认为失败节点不再可用，并且从<group>资源中移除对应的失败节点成员。例如，图13的消息重发处理是在不应用3gpp1320的mems组发送的情况下实现的。

图14示出了根据本发明实施例的消息重发处理的示例。特别地，图14涉及使用mbms的消息重发处理。

本发明提出了一种<retransmission>资源来支持多播重发。当多播消息传递失败时，<retransmission>资源被创建为<group>资源的子资源。组托管cse1430为<retransmission>组中列出的成员1510执行给定次数的多播。在每次重发的情况下，当节点成功地接收到消息时，成员可以从<retransmission>资源中移除。此外，在执行多播的次数达到给定的最大数量之后，<retransmission>可以被移除。特别地，必须为<retransmission>资源中的指定成员创建和配置用于执行3gppmbmstmgi和3gppmbms的相关信息。<retransmission>资源可以是<group>资源的子资源，也可以是临时独立资源。例如，在临时独立资源的情况下，必须维护与原始<group>资源的链接。

图17是示出根据本发明的装置配置的示例的视图。参照图17，设备1700可以包括存储器1710、处理器1720、收发机1730以及外围装置1740。此外，例如，设备1700还可以包括另一配置，并且不限于上述实施例。在本文中，作为示例，设备可以是基于上述m2m系统操作的装置。更具体地，图17的设备1700可以是诸如m2m设备、m2m网关以及m2m服务器的m2m网络节点的说明性硬件/软件架构。具体地，例如，存储器1710可以是不可移除存储器或可移除存储器。此外，例如，外围装置1740可以包括显示器、gps或其他外围装置，并且不限于上述实施例。此外，例如，上述设备1700可以是节点。特别地，类似于收发机1730，节点可以包括通信电路。基于此，节点可以执行与外部设备的通信。

此外，作为示例，处理器1720可以是通用处理器、数字信号处理器(dsp)、dsp核心控制器、微控制器、专用集成电路(asic)、现场可编程门阵列(fpga)电路、任何其它类型的集成电路(ic)以及与状态机相关的一个或多个微处理器中的至少一个。换言之，处理器可以是起控制作用的用于操作上述设备1700的硬件/软件配置。特别地，处理器1720可以被配置为执行存储在存储器1710中的计算机可执行命令，以实现节点的各种必要功能。例如，处理器1720可以被配置为执行信号编码、数据处理、功率控制、输入和输出处理以及通信中的至少任一项操作。此外，处理器1720可以控制物理层、mac层以及应用层。此外，例如，处理器1720可以在接入层和/或应用层中执行认证和安全处理，不限于上述实施例。

此外，例如，处理器1720可以被配置为通过收发机1730执行与其他设备的通信。例如，处理器1720可以被配置为执行计算机可执行命令，从而可以控制节点通过网络执行与其他节点的通信。换言之，可以控制在本发明中执行的通信。作为示例，其他节点可以是m2m网关、m2m服务器和其他设备。例如，收发机1730可以被配置为通过天线发射rf信号。收发机1730可以基于各种通信网络发送信号。此外，作为示例，mimo技术和波束成形技术可以作为天线技术应用，但不限于上述实施例。此外，通过收发机1730发送和接收的信号可以通过被调制和解调由处理器1720操作，这不限于上述实施例。

图18可以是设备的另一个装置配置。参照图18，如上所述，该设备可以由处理器进行操作。在本文中，作为示例，可以包括存储器、ram、rom以及网络。此外，可以还包括另一个可移动存储器，并且不限于上述实施例。在本文中，处理器可以被控制以执行基于存储在上述存储器中的信息的命令，并且执行本发明中描述的操作。此外，处理器可以由电源提供电力并且由外设提供输入信息，这不限于上述实施例。此外，作为示例，设备可以基于gps等获得位置信息和相关信息。此外，作为示例，设备可以基于其他输入设备接收输入信息，并且不限于上述实施例。

本发明的上述示例性实施例可以通过各种方式来实现。例如，本发明的实施例可以通过硬件、固件、软件或其组合来实现。

本发明的优选实施例的前述描述已经为本领域技术人员提供以实现和执行本发明。尽管已经参照本发明的优选实施例给出了前面的描述，但是对于本领域技术人员来说显而易见的是，在不脱离由所附权利要求限定的本发明的精神或范围的情况下，可以对本发明进行各种修改和变化。因此，本发明并不旨在限制于本文所示的实施例，而是将被赋予与本文所公开的原理和新颖特征相一致的最广泛的范围。

此外，虽然已经特别地示出了和描述了本说明书的优选实施例，但是应当理解，本说明书不限于上述实施例，相反，本领域技术人员将理解，可以进行各种改变和修改，而不脱离如下面的权利要求所限定的本说明书的精神和范围，并且不应当从本说明书的技术思想和展望单独地理解这些改变和修改。

在本说明书中，对本发明和方法发明都进行了说明，并且可以根据需要对这两个发明的描述进行补充。此外，已经参照本发明的优选实施例描述了本发明。本领域技术人员将理解，在不脱离本发明的基本特征的情况下，可以在其中进行形式和细节上的各种改变。因此，所公开的实施例应当被认为是说明性的而不是限制性的。本发明的范围由所附权利要求书而不是由前面的描述限定，并且在其等同物范围内的所有差异应被解释为包括在本发明中。

本发明不仅可以应用于onem2m系统，而且可以应用于各种系统。