Automated relationship management of service layer entities in communication networks

Abstract

The present invention describes systems and methods for automatically managing relationships between IoT entities (e.g., devices, applications, users) and removing the burden of managing these relationships from users. A relationship management service (RM service) for autonomous establishment, modification, and teardown of relationships between IoT entities is described herein.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of the filing date of U.S. Provisional Patent Application No. 62 / 713,779, filed on August 2, 2018, entitled “Methods to Automate Relationship Management of M2M / IOT Service Layer Entities.” Background Art

[0003] The M2M / IoT Service Layer ("Service Layer" or "SL") is a technology specifically targeted at providing value-added services for M2M / IoT devices, applications, and data. Recently, several industry standard bodies (such as oneM2M, ETSI, OCF, and LWM2M) are developing M2M / IoT SL to address the challenges associated with integrating M2M / IoT devices, applications, and data into Internet / World Wide Web, cellular networks, enterprise networks, and home network deployments.

[0004] The M2M / IoT SL may provide application and device access to a comprehensive set of M2M / IoT-oriented capabilities. Exemplary capabilities may include security, charging, data management, device management, discovery, provisioning, and connection management. Such capabilities may be made available to applications by leveraging the message formats, resource structures, and resource representation APIs supported by the M2M / IoT SL.

[0005] From the perspective of the protocol stack, SL can usually be located above the application protocol layer and provide value-added services to the applications it supports. Therefore, SL is often classified as a "middleware" service. Figure 1 An exemplary service layer between an application protocol and an application is shown.

[0006] From a deployment perspective, M2M / IoT SL can be deployed on various types of network nodes, including servers, gateways, and devices, as shown in Figure 2 As shown in .

[0007] The oneM2M standard defines M2M / IoT SL. The purpose of SL is to provide "horizontal" services that can be utilized by different "vertical" IoT systems and applications, such as e-health, fleet management and smart home. Figure 3The architecture of oneM2M SL shown in defines a common service entity (CSE) that can support four reference points. The Mca reference point can interface with the application entity (AE). The Mcc reference point can interface with another CSE within the same service provider domain, and the Mcc reference point can interface with another CSE in a different service provider domain. The Mcn reference point can interface with the underlying network service entity (NSE). The NSE can provide underlying network services for the CSE, such as device management, location services, and device triggering. The CSE can contain multiple logical functions called "common service functions (CSF)", such as "discovery", "data management and repository". Figure 4 The CSF supported by oneM2M is shown.

[0008] In describing SL, the following definitions are useful. Although the following definitions are described with respect to M2M / IoT systems, the definitions may also be applicable to any such similar systems.

[0009] The M2M / IoT Service Layer (SL) can be a software middleware layer that supports value-added services for M2M / IoT applications and services through a set of application programming interfaces (APIs) and underlying network interfaces. The SL can include the total set of M2M / IoT services that can be used by devices, applications, and users. The SL can also host resources.

[0010] An M2M / IoT application may be a software entity that registers with the M2M / IoT service layer and implements application specific functions related to a specific M2M / IoT use case, such as e-health, smart energy or home automation.

[0011] The M2M / IoT entity may be an M2M / IoT application or an M2M / IoT device or a user of an M2M / IoT application or an M2M / IoT device.

[0012] An M2M / IoT service may be a software entity that provides various capabilities for an M2M / IoT entity (eg, data management, security, device management).

[0013] The service layer entity may be an M2M / IoT entity registered and / or registered with the M2M / IoT service layer. Examples thereof may include instances of M2M / IoT applications or M2M / IoT service layers.

[0014] A resource (or service layer resource) may be a uniquely addressable object (ie, a data structure) that contains information (eg, data) and may be hosted by the M2M / IoT service layer.

[0015] A service layer device may be an entity registered with the M2M / IoT service layer and may host one or more applications.

[0016] A service layer primitive may be a message that uses a service layer API to access data or services provided by the service layer. A service layer request and a service layer response are examples of service layer primitives.

[0017] A service layer request may be an operation issued by a service layer entity for a service layer response.

[0018] M2M / IoT service layer registration may be an action of an M2M / IoT service layer entity registering to the M2M / IoT service layer.

[0019] An M2M / IoT registrant may be an M2M / IoT entity that registers with or uses an M2M / IoT service layer, such as an application, sensor, device, and / or other M2M / IoT service layer.

[0020] The M2M / IoT service platform may be a platform deployed by an M2M / IoT service provider and may optionally host an M2M / IoT service layer.

[0021] The M2M / IoT service provider may be a stakeholder (eg, a company) responsible for the deployment and management of the M2M / IoT service platform.

[0022] An M2M / IoT service subscriber may be a stakeholder (eg, a human being) who establishes a subscription (ie, registers) with an M2M / IoT service provider in order to access and use its M2M / IoT services.

[0023] M2M / IoT service registration may be an action by which an M2M / IoT service subscriber establishes a service subscription with an M2M / IoT service provider and registers its devices, applications, data, and authorized users with the service provider's platform.

[0024] An M2M / IoT user may be an authorized entity associated with an M2M / IoT service subscriber. An M2M / IoT service subscriber may grant specified privileges to a specified M2M / IoT user to access specified devices, applications, data, and services through the M2M / IoT service provider's platform.

[0025] Persistence as described herein may refer to data storage in a computer system that extends beyond the operations that created the data. Such data may remain in the computer system until it is deleted or destroyed. Pre-persistence may refer to procedures implemented before storing the data. Post-persistence may refer to procedures implemented after storing the data.

[0026] Metadata may be data that provides information about other data.

[0027] The oneM2M architecture is a distributed architecture and supports the deployment of M2M / IoT services in a distributed manner across the following node types: Application Service Node (ASN); Application Dedicated Node (ADN); Middle Node (MN); Infrastructure Node (IN); and Non-oneM2M Node (NoDN).

[0028] An ASN is a node that includes a CSE and includes at least one application entity (AE). In an exemplary embodiment, the ASN may reside in an IoT device.

[0029] An AND is a node that includes at least one AE and may not include a CSE. In an exemplary embodiment, an application-specific node may reside in a constrained IoT device.

[0030] A MN is a node that includes a CSE and includes zero or more AEs. In an exemplary embodiment, the MN may reside in an IoT gateway.

[0031] An IN is a node that includes a CSE and includes zero or more AEs. A CSE in an IN may include CSE functions that are not applicable to other node types. In an exemplary embodiment, an IN may reside in an IoT service infrastructure.

[0032] A non-oneM2M node is a node that may not include a oneM2M entity (neither AE nor CSE). Such a node may represent a node attached to the oneM2M system for interworking purposes (including management).

[0033] exist Figure 5 The configuration of various entities supported by the interconnection within the oneM2M system is shown in FIG. Summary of the invention

[0034] Managing relationships between M2M / IoT entities in an M2M / IoT deployment is traditionally performed by one or more users. However, in large-scale M2M / IoT deployments, as relationships become more complex, relying on users to manage relationships may become unsustainable. Relying on users to manually configure relationships between devices using applications that are only set up to configure device types from specific manufacturers is not an efficient and scalable approach. Furthermore, user management of ephemeral and dynamic relationships between M2M / IoT devices is not only burdensome to the user, but may also be suboptimal from a system scalability perspective.

[0035] Systems and methods for automatically managing relationships between IoT entities (e.g., devices, applications, users) and removing the burden of managing these relationships from users are described herein. Relationship management services (RM services) for autonomous establishment, modification, and teardown of relationships between IoT entities are described herein.

[0036] The Summary of the Invention section is provided to introduce various concepts that will be further described in the Detailed Description section below in a simplified form. The Summary of the Invention section is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the disadvantages mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] A more detailed understanding may be obtained through the following description given by way of example in conjunction with the accompanying drawings, in which:

[0038] Figure 1 An exemplary protocol stack having an application protocol and a service layer between the applications is shown;

[0039] Figure 2 An exemplary M2M / IoT deployment is shown;

[0040] Figure 3 An exemplary oneM2M service layer architecture is shown;

[0041] Figure 4 shows an exemplary CSF currently defined by oneM2M;

[0042] Figure 5 shows an exemplary configuration supported by oneM2M;

[0043] Figure 6 An example of relationship management service (RM service) deployment is shown;

[0044] Figure 7 An exemplary flow chart of RM service is shown;

[0045] Figure 8 An exemplary use case corresponding to the RM service is shown;

[0046] Fig.9A -B shows an exemplary sequence diagram of RM service processing;

[0047] Fig.10 An exemplary Common Service Entity (CSE) implementing RM service functions is shown;

[0048] Fig.11 Exemplary oneM2M resources are shown;

[0049] Fig.12 Exemplary oneM2M resources are shown;

[0050] Fig.13A -B shows an exemplary sequence diagram of RM service processing in the oneM2M system;

[0051] Fig.14 An exemplary graphical user interface (GUI) is shown;

[0052] Fig.15A is a system diagram of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or World Wide Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0053] Fig. 15B Yes, you can Fig.15A A system diagram of an exemplary architecture used within an M2M / IoT / WoT communication system shown in;

[0054] Fig. 15C Yes, you can Fig.15A and 15B A system diagram of an exemplary communication network node used within a communication system, such as an M2M / IoT / WoT device, gateway or server, as shown in FIG.

[0055] Fig.15D It can be implemented in Fig.15A and 15B A block diagram of an exemplary computing system of a node of a communication system. DETAILED DESCRIPTION

[0056] In large-scale M2M / IoT (hereinafter referred to as "IoT") deployments, managing relationships between IoT entities such as devices, applications, and users can be complex and difficult. Some examples of relationships may include (but are not limited to) managing which devices and / or applications are compatible with each other, which devices and / or applications have dependencies on each other, or which devices and / or applications are affiliated with one or more users. For example, compatibility may be defined to mean that devices can send messages to each other using protocol or message format translation, dependency may be defined to mean that one device cannot fully function without the other, and affiliation may be defined to mean that two devices are owned by the same organization.

[0057] Traditionally, the relationship between IoT entities is defined and configured by users. This can be implemented by users configuring the relationship between IoT devices using applications developed by device manufacturers (or third-party application developers). For example, smart home devices can be accompanied by applications developed by manufacturers, which customers can use to configure devices when deploying devices at home. Users can use such applications to configure individual smart home devices and groups of similar smart home devices. The configuration process may generally involve defining relationships between devices by one or more users. These relationships can define which smart devices control other smart devices and how the devices can be controlled. For example, a configuration application can allow users to configure which smart bulbs in their homes are controlled by buttons pressed or voice commands issued to smart light switch devices. Similarly, the configuration application can also allow users to configure actions implemented on smart bulbs when commands are issued by smart light switches, such as turning on / off, dimming, changing colors, or flashing lights.

[0058] The use case described above is a very common one, where the user plays an integral role in the configuration of the relationships between IoT devices with the help of an application. In small-scale IoT deployments of this type, the relationships tend to be shallow and involve only a few devices with long-term relationships that last for a long time (e.g., years) without modification. Therefore, this type of user configuration is sufficient.

[0059] For larger scale IoT deployments (e.g., smart cities), managing the relationships between IoT devices may be much more complex than for small scale IoT deployments. Larger scale IoT deployments may have higher complexity due to several factors, such as the large number of devices, different types of devices and their manufacturers, public / multi-tenant devices, and the temporal or spatial nature of the relationships between IoT devices that exist in such large scale deployments. In these types of large scale IoT deployments, relying on users to manually configure the relationships between devices using applications that are only established to configure device types from specific manufacturers is not an efficient and scalable approach. Furthermore, having users manage the ephemeral and dynamic relationships between IoT devices is not only burdensome for the user, but may also be suboptimal from a system scalability perspective.

[0060] The use case for smart cities illustrates the problem described above. Take, for example, a smart city that has established an intelligent public transportation system including driverless vehicles, which can dynamically connect and disconnect from each other to form a train of driverless vehicles. Such connections and disconnections can be based on scenarios such as: vehicles that are located near the same location and traveling in the same direction; passengers in one vehicle need to meet other passengers in other vehicles; passengers or cargo need to be transferred between vehicles; and / or one vehicle needs fuel (such as batteries) and other vehicles have spare fuel that can be shared. The city may eventually want to use its IoT SL platform to manage the dynamic connection and disconnection of vehicles. However, the city's IoT platform lacks the ability to configure and control relationship standards for the driverless vehicles that make up the intelligent transportation system. For example, the city's IoT platform lacks the ability to define standards such as: compatibility relationship standards; state relationship standards; location relationship standards; and scheduling relationship standards.

[0061] Compatibility standards could define the makes and models of autonomous vehicles that are compatible with each other and able to connect and disconnect.

[0062] State relationship criteria may define state-based criteria for when vehicles should connect or disconnect. Examples of such criteria may include criteria defining thresholds for when a vehicle's battery is considered low and needs to be charged and thresholds for when a vehicle's battery is considered high enough so that the vehicles can connect and share their battery power, or criteria defining when one vehicle is at maximum passenger capacity and the other vehicle is not at maximum passenger capacity so the vehicles can connect and exchange passengers.

[0063] The location relationship criteria may define criteria for when vehicles should connect based on current location (eg, less than 1 mile) and / or intermediate stopovers or destination locations.

[0064] The dispatch relationship criteria may define criteria for when vehicles should be connected based on their dispatch. An example of such a criterion may include two vehicles traveling in the same direction at similar times.

[0065] Among other things, the capabilities and exemplary embodiments described herein may provide solutions to the problems described above. Systems and methods for automatically managing relationships between IoT entities (e.g., devices, applications, users) and removing the burden of managing these relationships from users are described herein. Relationship management services for implementing these capabilities and functions are described herein.

[0066] The RM service can provide several functions. The RM service can be configured with RM policies, which define relationship management rules that the RM service can use to manage relationships between IoT entities. The RM service can manage different types of relationships between IoT entities, such as relationships based on functional compatibility between IoT entities, functional dependencies between IoT entities, conditional states of IoT entities, users attached to IoT entities, locations of IoT entities, and scheduling of IoT entities. The RM service can trigger the autonomous establishment, modification, and removal of relationships between IoT entities based on the RM trigger criteria defined by the RM policy. In order for the RM service to establish and maintain relationships between IoT entities, the specified RM trigger criteria defined in the RM policy should be met. If the RM trigger criteria are not met, the SL cannot establish new relationships and can remove existing relationships (if any). The RM service can dynamically collect RM contexts during normal SL operation (that is, during the processing of incoming requests and outgoing responses to / from IoT entities). The RM service can determine which SL context is relevant to the RM based on the RM trigger criteria defined in its configured RM policy. The RM service can then analyze the context against the RM policy to detect opportunities that will trigger the autonomous establishment, modification, or removal of relationships between IoT entities. During the management lifecycle of a relationship, the RM service may implement RM actions. RM policies may define separate sets of RM actions that the RM service may implement. These RM actions may be triggered by corresponding RM action trigger criteria, or when the RM service triggers the establishment, modification, or removal of a relationship between IoT entities based on the RM trigger criteria and the RM context. The RM service may maintain the RM state within the SL, which may be used by the RM service and other IoT entities to track the relationship between IoT entities.

[0067] SL can support relationship management services (RM services) that can autonomously establish, modify, and dismantle relationships between IoT entities. The types of IoT entity relationships that can be managed by RM services may include (but are not limited to) relationships based on functional compatibility between IoT entities, functional dependencies between IoT entities, conditional states of IoT entities, users attached to IoT entities, locations of IoT entities, and scheduling of IoT entities. Figure 6 As shown in , the RM service can be supported as a service within the IoT SL hosted on a server, gateway, or device.

[0068] like Figure 7As shown in , the RM service can be configured with an RM policy that defines relationship management rules that the RM service can use to manage the establishment, modification, and removal of relationships between IoT entities. The RM service can dynamically collect RM contexts that are relevant to relationship management between IoT entities. The RM service can then analyze the context against the RM policy to determine opportunities that will trigger the autonomous establishment, modification, or removal of relationships between IoT entities. The RM policy may include RM trigger criteria that can be used by the RM service to determine the type of relationship to be established, modified, or removed. The RM service can maintain a state corresponding to the relationship between the IoT entities it manages. Such an RM state can be maintained within the SL so that the RM service and other IoT entities can use the state to track the relationship. Once the relationship between IoT entities is established by the RM service, the RM service can support RM actions that provide value-added functions to the IoT entities involved in the relationship. The types of RM actions that the RM service can implement include (but are not limited to) relationship-based group management, event management, credential management, authorization management, request response, QoS management, and scheduling management.

[0069] Figure 8 An example of a RM service use case is provided. In this use case, the RM service can determine several types of relationships between a set of smart door locks installed in a user's home and a smart door lock application hosted on the user's smartphone. Figure 8 As shown in , both smart door locks and applications can be registered to a common SL that supports RM services. The RM service can determine and establish functional compatibility relationships between door locks and applications that work together, functional dependency relationships of door locks for applications that control door locks, user relationships between smart door locks and applications associated with the same user, and location relationships between smart door locks installed in the user's home. Based on these established relationships, the RM service can provide relationship-based capabilities for smart door locks, applications, and users. For example, the RM service can determine based on the configured policy that home automation devices at home should be associated with users. Based on this information, the RM service can automatically configure security credentials to door locks and applications, configure SL access control policies so that only authorized user applications lock / unlock door locks, and create SL groups including door locks so that users can lock / unlock one or more door locks by issuing a single request. By doing so, the RM service (through its relationship-based capabilities) automatically configures and manages door locks and applications and unloads the burden from users.

[0070] continue Figure 8In the example shown in , a request can be initiated by the RM service to trigger the door lock and application involved in the relationship to register with the service provider, boot SL credentials, establish a network connection to the SL, register with the SL, and / or implement a specified request on a specified SL resource. Similarly, a request can also be initiated by the RM service to create, boot, refresh or revoke SL credentials for the door lock and application involved in the relationship. Such SL credentials can be used by the door lock and application to authenticate with the SL itself and / or with other IoT entities involved in the relationship and establish a secure and trusted relationship.

[0071] The RM service may support capabilities used to autonomously establish, modify, and tear down relationships and provide value-added functions to IoT entities involved in the relationships. The RM service may support, for example (but not limited to), one or more of the following capabilities.

[0072] The RM service may be configured with RM policies, which may be used to manage the establishment, modification, and removal of relationships between IoT entities.

[0073] RM services can autonomously establish, modify, and tear down different types of relationships between IoT entities based on the dynamic collection and evaluation of RM contexts against RM trigger criteria defined within RM policies.

[0074] RM services can be configured with RM actions and RM trigger criteria that define whether / when the RM service implements the RM actions. For example, when establishing, modifying or tearing down a relationship between IoT entities, the RM service can implement the RM actions defined by the RM policy.

[0075] The RM service may manage the creation, configuration, and teardown of IoT entity groups based on one or more relationships between IoT entities and the definition of RM actions defined within RM policies.

[0076] The RM service may send notifications to IoT entities involved in a relationship or IoT entities interested in a SL relationship to indicate if / when a relationship is established, modified, or torn down. Notifications may be sent as a result of subscriptions created by the RM service based on RM actions defined within RM policies.

[0077] The RM service may send requests to trigger the IoT entity involved in the relationship so that the IoT entity registers with the service provider, bootstraps SL credentials, establishes a network connection to the SL, registers with the SL, and / or performs specified requests on specified SL resources. The request may be initiated as a result of an RM action defined in an RM policy.

[0078] The RM service may send requests to create, bootstrap or revoke SL credentials for one or more IoT entities involved in a relationship. These SL credentials may be used by the IoT entities to authenticate with the SL itself and / or with other IoT entities involved in the relationship and establish a secure and trusted relationship. The request may be initiated as a result of an RM action defined within an RM policy.

[0079] The RM service can initiate a request to the SL on behalf of the IoT entities involved in the relationship to create, retrieve, update or delete one or more resources hosted by the SL or IoT entity. The request can be initiated as a result of an RM action defined in the RM policy.

[0080] If / when a relationship is established, modified or torn down between IoT entities, the RM service may initiate a request to create, update or delete a subscription to a SL resource, respectively. The request may be initiated as a result of an RM action defined within an RM policy.

[0081] If / when a relationship is established, modified, or torn down between IoT entities, the RM service may initiate a request to create, update, or delete a SL access control policy, respectively. The request may be initiated as a result of an RM action defined within an RM policy.

[0082] If / when a relationship is established, modified, or torn down between IoT entities, the RM service may initiate a request to configure, reconfigure, or delete Quality of Service (QoS) policies and / or parameters in the underlying communication network interconnecting to the IoT entities. The request may be initiated as a result of an RM action defined within an RM policy.

[0083] If / when a relationship is established, modified, or torn down between IoT entities, the RM service may initiate a request to configure, reconfigure, or delete scheduling-related policies and / or parameters associated with the IoT entities. Scheduling may control the time when an IoT entity is connected to the network and available for communication, and / or the time when an IoT entity performs a specific operation (e.g., when a switch is turned on / off). Requests may be initiated as a result of RM actions defined within RM policies.

[0084] The RM service may allow users to explicitly define and create their own relationships through the capabilities of the RM service. The RM service may then manage these relationships on behalf of the user.

[0085] As described, the foregoing exemplary capabilities may rely on a relationship management policy (RM policy).

[0086] The RM service may be configured with RM policies that define relationship management rules that the RM service may use to establish, modify, and tear down relationships between IoT entities. Such rules may be defined by RM policy attributes such as (but not limited to) those set forth in Table 1. It should be understood that the RM policy may include one or more data structures to store such attributes.

[0087] Table 1 - Relationship Management (RM) Strategies

[0088]

[0089]

[0090] RM services can manage different types of relationships between IoT entities. RM policies can identify the relationships that the RM service will manage. RM trigger criteria defined within RM policies can be used by RM services to determine whether a relationship of a specified type can be established, modified, or torn down between IoT entities.

[0091] The supported relationship types may include (but are not limited to) one or more of the following: function compatibility relationship; function dependency relationship; function status relationship; user relationship; location relationship; scheduling relationship; semantic relationship; service ordering relationship; agent relationship; route relationship; and sequence relationship.

[0092] Functional compatibility relationships may be relationships defined by their functional compatibility based on the functional types and capabilities of IoT entities. For example, smart light switches manufactured by different manufacturers may have a compatibility relationship because they are both light switches that can be used to control smart light bulbs or can communicate using the same protocol or message format.

[0093] A functional dependency relationship may be a relationship defined by a functional dependency of an IoT entity on one or more other IoT entities based on the functional type and capability of the IoT entity. For example, a smart light bulb may have a dependency relationship on a smart light switch used to control the smart light bulb.

[0094] A functional state relationship may be a relationship defined by the past or current functional state of one or more IoT entities. For example, all smart light bulbs that are currently lit may have a state relationship with each other.

[0095] A user relationship may be a relationship defined by the affiliation of an IoT entity to a common user. For example, all smart light switches that a user has the authority to control may have a user relationship with each other.

[0096] A positional relationship may be a relationship defined by the location of IoT entities with respect to each other and with respect to a specified range or boundary. For example, a smart light bulb and a switch installed in the same room may have a positional relationship with each other.

[0097] A scheduling relationship may be a relationship defined by corresponding schedules of IoT entities. For example, light bulbs scheduled to turn on / off at the same time of day may have a scheduling relationship.

[0098] Semantic relations can be relations between IoT entities defined based on their semantic descriptions (i.e., semantic ontology defines relations between IoT entities). For example, a semantic ontology can be used to describe the semantic relations of a light switch controlling a light bulb.

[0099] The service subscription relationship may be a relationship defined by a common service subscription shared between IoT entities. For example, a smart light bulb and a switch registered to the same IoT service provider by the same service subscriber may have a service subscription relationship.

[0100] A proxy relationship may be a relationship between one IoT entity group and another IoT entity that acts as a proxy for the IoT entity group.

[0101] A route relationship may be a relationship between a set of IoT entities located along a predefined route, such as the section of I-276 between PA Turnpike exits 309 and 333. Such a relationship may be particularly useful for the smart public transportation embodiments described below.

[0102] A sequential relationship can be a relationship between a set of IoT entities that exists in a process with sequential dependencies (such as an assembly line in a factory).

[0103] The RM service can trigger the autonomous establishment, modification and removal of relationships between IoT entities based on the RM trigger criteria (or trigger conditions) defined by the RM policy. In order for the RM service to establish and maintain relationships between IoT entities, the specified RM trigger criteria defined in the RM policy should be met. If the RM trigger criteria are not met, the SL cannot establish new relationships and can remove existing relationships (if any). The RM policy can define different types of RM trigger criteria, which may include (but are not limited to) one or more of the following: compatibility relationship criteria; dependency relationship criteria; state relationship criteria; user relationship criteria; location relationship criteria; scheduling relationship criteria; semantic relationship criteria; service subscription relationship criteria; agent relationship criteria; route relationship criteria; and sequence relationship criteria.

[0104] Compatibility relationship criteria may define IoT entities that are functionally compatible with each other. For example, RM trigger criteria may refer to industry standards and / or product profiles associated with the standards that may be used to compare and determine whether IoT entities are functionally compatible with each other (e.g., a compatibility relationship may be established between Bluetooth smart light bulbs, even if they are manufactured by different vendors). In another example, RM trigger criteria may define SL conditions, such as the occurrence of the same type of SL request message being sent to two or more IoT entities on a repeated basis. In this case, the RM service may determine that the IoT entities are compatible based on its ability to handle the same type of request or message format.

[0105] Dependency relationship criteria may define IoT entities that have functional dependencies on one or more other IoT entities. For example, such criteria may refer to industry standards and / or product profiles associated with such standards that may be used by the RM service to determine whether IoT entities are dependent on each other (e.g., a Bluetooth smart light bulb depends on a Bluetooth smart light switch). In another instance, the RM trigger criteria may define SL conditions, such as the same IoT entity sending a SL request message to another IoT entity on a repeated basis. In this case, the RM service may detect dependency relationships between IoT entities. By detecting that two IoT entities have a dependency, the service layer may generate a warning to the service layer owner or operator if a particular device is taken offline. For example, the service layer may notify the portal owner that the door lock may soon lose functionality due to low battery, and that this will affect the performance of the home security system.

[0106] The state relationship criteria can define IoT entities that have a state relationship with each other. In one embodiment, the name and value of (multiple) specified IoT entity attributes can be used as a criterion to determine whether a state relationship exists between IoT entities (e.g., multiple Bluetooth smart bulbs are lit).

[0107] The user relationship criteria may define IoT entities that have a user relationship with each other. For example, the identifiers of the user(s) and the IoT entity(s) identified by the user(s) may be used as criteria to determine whether a user relationship exists between IoT entities (e.g., multiple Bluetooth smart light switches may be controlled by the same user).

[0108] The location relationship criteria can define IoT entities that have a location relationship with each other. For example, a specified location can be used as a criterion to determine whether there is a location relationship between IoT entities (such as multiple Bluetooth smart light bulbs installed in the same room).

[0109] The scheduling relationship criteria may define IoT entities that have a scheduling relationship with each other. For example, a specified schedule may be used as a criterion to determine whether a scheduling relationship exists between IoT entities (e.g., multiple Bluetooth smart light bulbs turn on and / or off at a specific time). In another example, a specified schedule may provide an indication that two devices may or may not need to wake up at the same time when they communicate. For example, if a system (e.g., a gateway (GW)) is able to buffer messages sent between devices, the devices may not need to wake up at the same time.

[0110] Semantic relationship criteria may define IoT entities that have semantic relationships with each other. For example, a specified semantic description / ontology may be used as a criterion to determine whether a semantic relationship exists between IoT entities (e.g., a semantic ontology may define that a smart light switch is used to control the state of a smart light bulb).

[0111] The service subscription relationship standard can define IoT entities that have a service subscription relationship with each other. For example, a specified service subscriber can be used to determine whether IoT entities have the same service subscriber and therefore have a service subscriber relationship (e.g., all smart light bulbs and switches are registered to the same IoT service provider by the same service subscriber).

[0112] The proxy relationship criteria may define IoT entities that have a proxy relationship with each other. For example, a list of IoT entities registered to another IoT entity may be used as a criterion to determine whether a proxy relationship exists between IoT entities.

[0113] Route relationship criteria can define IoT entities that have a route relationship with each other. For example, a route can be specified, and the route can include passing point definitions. The route can be used as a criterion to determine whether IoT entities have a route relationship with each other.

[0114] The order relationship standard can define IoT entities that have an order relationship with each other. For example, a pattern of operations implemented by a set of IoT entities can be defined. The pattern can be used to define the sequence relationship between IoT entities.

[0115] The different types of RM triggering criteria defined above may include, for example (but not limited to), the elements defined in Table 2.

[0116] Table 2 - Relationship Management (RM) Standards

[0117]

[0118]

[0119] During the management lifecycle of a relationship (i.e., establishment to modification to removal), the RM service may implement RM actions. RM policies may define separate sets of RM actions that the RM service may implement. RM actions may define actions that are implemented if / when corresponding trigger conditions as described herein are met for the action. In addition, the RM service may support a set of native RM actions that it may implement that are independent of those RM actions defined in RM policies.

[0120] RM policies may include one or more RM actions that the RM service may implement. RM actions may also include trigger conditions. If / when the RM service detects that a trigger condition is met for a certain action, the RM service may implement the action. A separate RM action may involve a request initiated by the RM service, the request having a defined operation for an IoT entity or another service hosted by the SL. Certain types of RM actions may involve the implementation of the request by the RM service on behalf of the IoT entity involved in the relationship. Such implementation may reduce the overhead and burden on the IoT entity, thereby freeing it from having to implement these requests itself. Other types of RM actions implemented by the RM service may provide additional value-added services to the SL itself. In implementing these actions, the RM service may utilize other services hosted in the SL. For example, the RM service may initiate a request for another service to cause it to send a trigger to a first IoT entity involved in a relationship with another IoT entity, thereby causing the first IoT entity to connect and register with the service provider and / or register with the SL.

[0121] The types of RM actions implemented by the RM service may include (but are not limited to) one or more of the following types. The RM service may implement these actions when the trigger conditions specified for these RM actions are met. The trigger conditions may be customized and configured individually for each RM action.

[0122] If / when a specified trigger condition is met (e.g., a relationship between IoT entities is established, modified, or removed), a request may be initiated by the RM service to send a notification to the IoT entity, wherein the notification may include, for example (but not limited to), the following RM status data:

[0123] - A list of identifiers of the IoT entities involved in the relationship. Such a list may also include what protocols the IoT entities use to communicate, what channels (frequencies) they use to communicate, what messaging protocols / formats (e.g. JSON, CBOR) they use to communicate, and / or reference IDs or keys that may be used to establish communications with one or more IoT entities;

[0124] - When the relationship was established;

[0125] - the planned dismantling time of the relationship;

[0126] - the identifier of the RM policy used to create the relationship; and

[0127] - One or more identifiers of SL resources created by the RM Service as a result of relationship establishment (eg, group, schedule, location and subscription resources).

[0128] Requests may be sent by the RM service to trigger the IoT entities involved in the relationship to register with the service provider, bootstrap SL credentials, establish a network connection to the SL, register with the SL, or perform specified requests on specified SL resources.

[0129] Requests may be initiated by the RM service to create, bootstrap, refresh or revoke SL credentials for one or more IoT entities involved in a relationship. These SL credentials may be used by the IoT entities to authenticate with the SL itself and / or with other IoT entities involved in the relationship and establish a secure and trusted relationship.

[0130] If / when specified trigger conditions are met, a request may be initiated by the RM service on behalf of the IoT entities involved in the relationship to create, retrieve, update or delete one or more resources hosted by the SL or IoT entity.

[0131] If / when specified trigger conditions are met (e.g., a relationship is established, modified, or torn down, respectively, between IoT entities), a request may be initiated by the RM service to create, update, or delete a group of IoT entities using SL resources. The RM service may keep updating the membership of the SL group to reflect the IoT entities involved in the relationship.

[0132] A request may be initiated by the RM service to create, update or delete a subscription to a SL resource if / when a specified trigger condition is met (e.g. a relationship is established, modified or torn down, respectively, between IoT entities). The RM service may keep updating the subscription to reflect the IoT entities involved in the relationship which will receive notifications of any changes to the subscription to the SL resource.

[0133] If / when specified trigger conditions are met (e.g., a relationship is established, modified, or torn down, respectively, between IoT entities), a request may be initiated by the RM service to create, update, or delete a SL access control policy. The access control policy may be configured with privileges that allow the IoT entities involved in the relationship to access each other's resources (i.e., data / data structures) stored in the SL and / or to send requests directly to each other. The RM service may keep updating the access control policy to reflect the IoT entities involved in the relationship and the operations required. Privileges may be defined by the RM action itself, the RM service may derive privileges based on checking the RM context (e.g., IoT entity profile information, the trust level of the IoT entity with other IoT entities, existing access control policies and privileges, etc.), or the RM service may consult other IoT entities to derive privileges that they may configure in the access control policy.

[0134] If / when specified trigger conditions are met (e.g., a relationship between IoT entities is established, modified, or torn down), a request may be initiated by the RM service to configure, reconfigure, or delete Quality of Service (QoS) policies and / or parameters in the underlying communication network interconnecting the IoT entities.

[0135] If / when specified trigger conditions are met (e.g., a relationship between IoT entities is established, modified, or torn down), a request can be initiated by the RM service to configure, reconfigure, or delete the scheduling policies and / or parameters of the IoT entities. The schedule can control the time when the IoT entity is connected to the network and available for communication, or the time when the IoT entity performs a specific operation (e.g., when a switch is turned on / off).

[0136] A request may be initiated by the RM service to create or update a charging record used to record RM actions. The charging record may be used to record that a relationship is formed, updated, or deleted. A user or subscriber may then be charged based on the charging record.

[0137] The RM service may dynamically collect contexts of IoT entities relevant to the RM during normal SL operation (i.e., during processing of incoming requests and outgoing responses to / from IoT entities). The RM service may determine which contexts are relevant to the RM based on the RM trigger criteria defined in its configured RM policies. The RM service may then analyze the contexts against the RM policies to determine opportunities that will trigger autonomous establishment, modification, or teardown of relationships between IoT entities.

[0138] RM contexts may include information that may be analyzed by RM services (e.g., for RM policies) to detect whether to trigger the establishment, modification, or removal of relationships between IoT entities. RM contexts may include, but are not limited to, one or more of the following: compatibility context; dependency context; state context; user context; location context; scheduling context; service subscription context; semantic context; proxy context; route context; and sequence context.

[0139] The compatibility context may include information that can be used by the RM service to determine compatibility between IoT entities. The compatibility context may include (but is not limited to) one or more of the following: manufacturer information (e.g., manufacturer name, model, and serial number); product profile information (e.g., type of device or application, such as what communication and messaging protocols or formats are supported); interface definitions (e.g., schema definitions, supported protocols); existing SL meta information (e.g., existing SL group information); and capability information corresponding to the IoT entity (e.g., capabilities or features).

[0140] A dependency context may include information that may be used by the RM service to detect dependencies of an IoT entity on other IoT entities. A dependency context may include a description of one or more required peer IoT entities on which a certain IoT entity has dependencies. Such a description may include, for example (but not limited to), one or more of the following: manufacturer information (e.g., manufacturer name, model, and serial number); product profile information (e.g., type of device or application, such as what communication and messaging protocols or formats are supported); interface definitions (e.g., schema definitions, supported protocols); existing SL meta information (e.g., existing SL group information); and capability information corresponding to the IoT entity (e.g., capabilities or features).

[0141] The state context may include information that can be used by the SL to determine the state of the IoT entity. The state context may include (but is not limited to) one or more of the following: the state of one or more specified IoT entity resources and attributes.

[0142] User context may include information that can be used by the SL to associate an IoT entity with a user. User context may include (but is not limited to) one or more of the following: SL meta-information (e.g., user profile information configured at registration or enrollment or at some time thereafter) that can be used to associate a user with an IoT entity.

[0143] The location context may include information that can be used by the SL to determine the location of the IoT entity. The location context may include (but is not limited to) one or more of the following: past, current or future planned location information provided by the IoT entity itself or by a third party.

[0144] The scheduling context may include information that can be used by the SL to detect the schedule of the IoT entity. The scheduling context may include (but is not limited to) one or more of the following: availability schedule (e.g., sleep schedule); and activity schedule (e.g., reporting interval of a sensor).

[0145] The service subscription context may include information that may be used by the SL to associate an IoT entity with a service subscription. The service subscription context may include (but is not limited to) one or more of the following: SL meta information that may be used to associate a service subscription with an IoT entity.

[0146] The semantic context may include information that can be used to detect semantic relationships. The semantic context may include (but is not limited to) one or more of the following: semantic information (e.g., query semantic ontologies and / or descriptors that describe one or more IoT entities and can be used to automatically associate IoT entities).

[0147] The proxy context may include information that may be used to detect proxy relationships. The proxy context may include, but is not limited to, one or more of the following: information about which IoT entities have other IoT entities registered with them and which can act as proxies on behalf of one or more types of functions or messages.

[0148] The route context may include information that can be used to detect route relationships. The route context may include (but is not limited to) one or more of the following: information describing the route, such as the location of the route, passing points along the route, the type of participants who compiled the route or used the route; and information describing the status of the route (e.g., congested, uncongested, etc.). Such route information may be used as a criterion to determine whether IoT entities have route relationships with each other.

[0149] A sequence context may include information that may be used to detect sequence relationships. A sequence context may include, but is not limited to, one or more of the following: information describing or providing information about the state of a sequence or pattern involving one or more IoT entities, such as a sequence of IoT entities performing operations in a particular sequence with respect to each other and the state of such operations.

[0150] Once the relationship between IoT entities is established, the RM service can maintain the RM state within the SL, which can be used by the RM service and other IoT entities to track the relationship. The RM state can store information about the relationship and can be maintained during the entire life cycle of the relationship (i.e., establishment to modification to removal) until the relationship is removed by the RM service.

[0151] The RM state may include attributes such as (but not limited to) the information presented in Table 3. In one embodiment, the RM service may create and maintain the RM state within one or more SL resources. SL resource trees may be created, updated, and deleted by the RM service when relationships are established, modified, and torn down, respectively. Such a SL resource tree may contain the information defined in Table 3. The RM service may make information about the relationships it maintains available for reading by other services and IoT entities. The information may be made accessible through resource reading. For example, the contents of Table 3 may be stored in a resource and represent a single relationship. The resource may be read by other services and IoT entities.

[0152] Table 3 - Relationship Management (RM) Status

[0153]

[0154]

[0155] Fig.9A -B shows an example of RM procedures involving an IoT SL that supports RM services and is hosted on an IoT server or gateway. Fig.9A - In B, the RM service manages the relationship between IoT devices and applications registered to the IoT SL.

[0156] As shown in step 0, RM policies can be optionally pre-provisioned into the RM service of the SL, and the RM policies include rules that provide guidance to the RM service for the establishment, modification, and removal of relationships between IoT entities. For example, the RM policy can be hard-coded into the RM service by the developer when the RM service is developed, pre-configured into the RM service when deployed, or configured using an out-of-band mechanism by a service provider who owns and operates the RM service within its service platform. Some examples of out-of-band mechanisms may include a management portal that presents a graphical user interface (GUI) and can be used by the service provider to configure and manage its platform or device management server, where the service provider uses the device management server to push the RM policy to the RM service in its service platform. The rules within the RM policy may include, for example, the following information: the type of relationship applicable to the policy, the RM trigger criteria that the RM service can use to trigger the establishment, modification, and / or removal of the relationship associated with the policy, and the RM actions that the RM service can implement when establishing, modifying, or removing the relationship associated with the policy.

[0157] As shown in step 1, each individual IoT entity (device, application, service subscriber, user, etc.) can communicate with the SL individually without establishing relationships between IoT entities, and therefore without utilizing any relationship-based capabilities of the SL. For example, an IoT entity can register with the SL individually and publish metadata describing itself to the SL (e.g., unique identifier, type, manufacturer, location, (multiple) users, schedule, etc.). The IoT entity can also start publishing and consuming data to / from the SL.

[0158] As shown in step 2, each individual IoT entity can send a request to the RM service in the SL to create a RM policy, which contains rules that provide guidance to the RM service for the establishment, modification and removal of relationships between IoT entities. Requests for the creation of RM policies can be issued by IoT entities at different times, such as when a service subscriber registers, or when a device, application or user implements a SL registration to the SL, or at some time thereafter. Such requests can also be triggered by a user operating a device. For example, a user can use a GUI to configure information in a device and initiate a request to the GW to request a relationship with a specific device.

[0159] At step 3, the RM service may collect RM contexts from metadata published by each individual IoT entity (e.g., device) that has registered and enrolled in the SL, and may also collect RM contexts from SL requests issued to and / or targeted at each individual IoT entity. This step may also involve interaction with IoT devices and / or applications, for example, the RM service may also collect RM contexts by other means, such as periodically sampling the states of the IoT entities involved in the relationship, or analyzing or detecting requests from IoT devices. The RM service may then analyze the RM contexts and the RM trigger criteria defined in the RM policy that has been created and configured within the RM service. Based on the RM trigger criteria defined in the RM policy, the RM service may evaluate the RM contexts it has collected to determine whether any RM trigger criteria are met to trigger the establishment of a relationship between applicable IoT entities.

[0160] At step 4, based on the RM trigger criteria defined in the RM policy, the RM service detects that a relationship can be established between IoT entities. By implementing the RM action in the following step 5, the RM service can trigger and establish a relationship of the type defined by the RM policy. Alternatively, the RM service can also allow IoT entities (such as user applications) to define and manually create relationships between IoT entities. This can be achieved by configuring the relationship into the RM service via an explicit request issued by the IoT entity ( Fig.9A - Not shown in B). Once created, the RM service can then manage the relationship.

[0161] At step 5, based on the RM actions defined in the RM policy, the RM service can implement RM actions when establishing relationships between IoT entities. Such RM actions can include requests implemented by the RM service on behalf of the IoT entities involved in the relationship. The RM service can also initiate requests to other services hosted in the SL to manage relationships. The RM service can initiate, for example (but not limited to), the following RM actions.

[0162] The RM service may initiate the creation of a SL group resource and may configure the IoT entities involved in a relationship as members of such a group.

[0163] The RM service may initiate the creation of a SL subscription on a SL resource and configure the SL to send notifications to the IoT entity(ies) involved in the relationship.

[0164] The RM service may initiate the generation and bootstrapping of SL credentials for the IoT entities involved in a relationship so that the IoT entities may communicate securely with each other.

[0165] The RM service may initiate the creation and / or configuration of access control privileges on SL resources that may be attached to IoT entities involved in a relationship, thereby allowing access to these resources by these IoT entities.

[0166] The RM service may initiate one or more SL requests for the IoT entities involved in the relationship.

[0167] The RM service may initiate the configuration of QoS parameters in the underlying transport network that may connect the IoT entities involved in the relationship.

[0168] The RM service may initiate configuration of scheduling parameters of the IoT entities involved in a relationship so that their schedules may be aligned with each other. Exemplary scheduling parameters may include sleep, communication or functional parameters, among others.

[0169] At step 6, after the relationship between IoT entities is established, the RM service may create a RM state, which may be used by the RM service to track the relationship and further manage it (eg, modify or tear down).

[0170] At step 7, after the relationship between the IoT entities is established, the RM service may optionally initiate notification of the relationship establishment to the IoT entities involved in the relationship and / or other IoT entities that may be interested in the established relationship (e.g., the IoT entity that created the RM policy). Such notification may include the RM state, which may include, for example (but not limited to), the following information:

[0171] - a list of identifiers of the IoT entities involved in the relationship;

[0172] - Relationship establishment time, which can be extended if the IoT application(s) and / or IoT entity(ies) perform relationship refreshes;

[0173] - the planned dismantling time of the relationship;

[0174] - the identifier of the RM policy used to create the relationship; and

[0175] - One or more identifiers of SL resources that the RM Service may create as a result of the relationship establishment (eg, group, schedule, location and subscription resources).

[0176] At step 8, after the RM service establishes the relationship between the IoT entities, the IoT entities involved in the relationship may be given the ability to interact and communicate with each other. Such ability may be achieved by the RM service creating and configuring appropriate SL groups, subscriptions, credentials, access control policies, prepaid requests, QoS configurations (multiple items) in the underlying network, and / or scheduling on behalf of the IoT entities involved in the relationship.

[0177] At step 9 , similar to step 3 , based on the RM trigger criteria defined within the RM policy, the RM service may evaluate the RM contexts it has collected to determine whether the criteria are met to trigger the modification of the relationship between applicable IoT entities.

[0178] At step 10, based on the RM trigger criteria defined in the RM policy, the RM service may determine that the relationship between IoT entities needs to be modified, refreshed, or terminated. The RM service may trigger the modification, refresh, or termination of the relationship and may implement the RM action in step 11.

[0179] At step 11, similar to step 5, based on the RM actions defined in the RM policy, the RM service can implement actions when it modifies the relationship between IoT entities. Such RM actions can involve the RM service implementing requests on behalf of the IoT entities involved in the relationship. The RM service can also initiate requests to other services hosted in the SL to manage the relationship. The RM service can initiate, for example (but not limited to), the following RM actions.

[0180] The RM service may initiate updates of SL group resources and may reconfigure IoT entities involved in relationships as members of such group resources.

[0181] The RM service may initiate updates of SL subscriptions on SL resources and may reconfigure the SL to send notifications to the IoT entity(ies) involved in the relationship.

[0182] Before the relationship is modified, the RM service may initiate the revocation of credentials from the IoT entities involved in the relationship. The RM service may then initiate the generation and bootstrapping of SL credentials for the IoT entities involved in the modified relationship, so that the IoT entities can communicate securely with each other.

[0183] Before the relationship is modified, the RM service may initiate the revocation of access control privileges from the IoT entities involved in the relationship. The RM service may then initiate the creation and / or configuration of access control privileges on SL resources attached to the IoT entities involved in the modified relationship, thereby allowing access to these resources by these IoT entities.

[0184] The RM service may initiate one or more SL requests for the IoT entities involved in the modified relationship.

[0185] The RM service may initiate reconfiguration of QoS parameters in the underlying transport network connecting the IoT entities involved in the modified relationship.

[0186] The RM service may initiate reconfiguration of scheduling parameters of the IoT entities involved in the modified relationship so that their schedules may be aligned with each other, such as sleep, communication or functionality.

[0187] At step 12, after the relationship between IoT entities is modified, the RM service may update the RM state stored in the SL. The RM service may also share the updated RM state with other IoT entities.

[0188] At step 13, after the relationship between IoT entities is modified, the RM service may optionally initiate notification of the modified relationship to the IoT entities involved in the relationship and / or other IoT entities that may be interested in knowing that the relationship has been modified (e.g., the IoT entity that created the RM policy). These notifications may include the RM state, which may include information such as (but not limited to) the following:

[0189] - an updated list of identifiers of the IoT entities involved in the modified relationship;

[0190] - the time when the relationship was modified;

[0191] - the planned dismantling time of the relationship;

[0192] - the identifier of the RM policy used to modify the relationship;

[0193] - Identifiers of SL resources that the RM service modifies as a result of relationship modification (e.g. groups, schedules, access control policies, locations and subscription resources); and

[0194] -Issuing new security credentials if existing security credentials are compromised.

[0195] At step 14, once the RM service modifies the relationship between IoT entities, the IoT entities involved in the relationship may be given the ability to interact and communicate with each other. Such an ability may be achieved by the RM service updating the appropriate SL groups, subscriptions, credentials, access control policies, prepaid requests, QoS configurations in the underlying network, and / or scheduling on behalf of the IoT entities involved in the relationship (as described in step 11). Updating such information may include updating resources stored in the service layer, or sending messages to (multiple) IoT devices or (multiple) IoT applications to update the resources of the (multiple) IoT devices or (multiple) IoT applications.

[0196] At step 15 , similar to step 3 , based on the RM trigger criteria defined within the RM policy, the RM service may evaluate the collected RM contexts to determine whether any RM trigger criteria are met to trigger the teardown of the relationship between applicable IoT entities.

[0197] At step 16, based on the RM trigger criteria defined within the RM policy, the RM service may determine that the relationship between the IoT entities needs to be removed. For example, the SL resources representing the IoT entity may have expired or may have been removed, thereby ending the relationship. The RM service may trigger the removal of a relationship. The RM service may also temporarily deactivate a relationship (not shown). For example, instead of removing a relationship that is not in use, the RM service may instead deactivate the relationship during an inactivity period and reactivate the relationship if / when activity from the relationship participants resumes. When a relationship is deactivated, the RM service may coordinate the deactivation of services based on the relationship (e.g., deactivating a SL group or subscription). The RM service may then reactivate services based on the relationship.

[0198] At step 17, similar to step 5, based on the RM actions defined in the RM policy, the RM service may perform actions when it tears down the relationship between IoT entities. Such RM actions may involve the RM service performing a request on behalf of the IoT entities involved in the relationship. The RM service may also initiate requests to other services hosted in the SL to manage the relationship. The RM service may initiate, for example (but not limited to), the following RM actions.

[0199] The RM service can initiate the deletion of SL group resources or members of SL group resources.

[0200] The RM service may initiate deletion of a SL subscription on a SL resource and send a notification indicating that the subscription was deleted.

[0201] The RM service may initiate the revocation of credentials from the IoT entities involved in the relationship being torn down.

[0202] The RM service may initiate the revocation of access control privileges from the IoT entities involved in the relationship being torn down.

[0203] The RM service may initiate one or more SL requests to the IoT entities involved in the relationship being torn down.

[0204] The RM service may initiate the revocation of QoS parameters in the underlying transport network of the IoT entities involved in the relationship that is being torn down.

[0205] The RM service may initiate the update or removal of scheduling parameters of the IoT entities involved in the relationship being torn down.

[0206] At step 18 , after the relationship between IoT entities is torn down, the RM service may update or delete the RM state stored in the SL.

[0207] At step 19, after the relationship between the IoT entities is torn down, the RM service may optionally initiate a notification regarding the relationship teardown. Such notifications may be sent to the IoT entities involved in the relationship and / or other IoT entities that may be interested that the relationship has been torn down (e.g., the IoT entity that created the RM policy). These notifications may contain the RM state, which may include information such as (but not limited to) the following:

[0208] - a list of identifiers of the IoT entities involved in the relationship being torn down;

[0209] - the time at which the relationship was dismantled;

[0210] - the identifier of the RM policy used to tear down the relationship; and

[0211] - Identifiers of SL resources (eg, group, schedule, location and subscription resources) that the RM Service updated and / or deleted due to relationship teardown.

[0212] Smart City Examples

[0213] Exemplary smart city embodiments of the introduced relationship management functionality are described herein. The exemplary embodiments describe one or more possible smart public transportation systems.

[0214] Smart cities may establish smart public transportation systems including driverless vehicles that can dynamically connect and disconnect from each other to form trains of driverless vehicles. Such connections and disconnections may be based on scenarios such as vehicles that are near the same location and traveling in the same direction, passengers in one vehicle need to meet other passengers in other vehicles, passengers or cargo need to be transferred between vehicles, or one vehicle needs fuel (e.g., batteries) and other vehicles have spare fuel that can be shared.

[0215] To manage the dynamic connection and disconnection of vehicles, cities can leverage their IoT SL platform that supports RM services. Cities can configure RM services with a set of RM policies that define RM trigger criteria for when autonomous vehicles should connect to each other (i.e., establish relationships) and disconnect from each other (i.e., tear down relationships). For example, cities can define the following RM trigger criteria: compatibility relationship criteria; state relationship criteria; location relationship criteria; scheduling relationship criteria; and user relationship criteria.

[0216] Compatibility standards could define the makes and models of autonomous vehicles that are compatible with each other and able to connect and disconnect.

[0217] State relationship criteria may define state-based criteria for when vehicles should connect or disconnect. Examples of such criteria may include criteria defining thresholds for when a vehicle's battery is considered low and needs to be charged and thresholds for when a vehicle's battery is considered high enough so that the vehicles can connect and share their battery power, or criteria defining when one vehicle is at maximum passenger capacity and the other vehicle is not at maximum passenger capacity so the vehicles can connect and exchange passengers.

[0218] The location relationship criteria may define criteria for when vehicles should connect based on current location (eg, less than 1 mile) and / or intermediate stopovers or destination locations.

[0219] The dispatch relationship criteria may define criteria for when vehicles should be connected based on their dispatch. An example of such a criterion may include two vehicles traveling in the same direction at similar times.

[0220] In addition to the RM policies and RM trigger criteria configured by the city, users may also be allowed to configure their own RM policies and RM trigger criteria.User relationship criteria may define criteria for when vehicles should connect based on user relationships, such as two users who know each other and wish to travel together.

[0221] Within the RM strategy, RM actions may also be defined by the city and / or the user. If / when the RM trigger criteria are met that cause vehicles to connect or disconnect from each other, the RM service may then implement such RM actions. For example, the following request may be initiated by the RM service.

[0222] A request may be initiated by the RM service to send a notification to the city's traffic command and control center about whether / when vehicles are connected and disconnected. The notification may include information such as, for example: a list of identifiers of the vehicles involved, the establishment time of the connection or disconnection, the planned disconnection time, and / or identifiers of SL resources created by the RM service as a result of the relationship establishment (e.g., group, schedule, location, and subscription resources).

[0223] Requests may be initiated by the RM service to trigger the connection or disconnection of vehicles involved in a relationship, thereby implementing a specified request on a specified SL resource (eg, providing a count of passengers in the vehicle, providing a battery level measurement, etc.).

[0224] A request may be initiated by the RM service to create, boot, or revoke SL credentials for one or more vehicles connected to each other. These SL credentials may be used by the vehicles to authenticate each other and establish a secure and trusted relationship so that they can communicate securely with each other.

[0225] If / when a vehicle is initially connected, another vehicle is added / removed, or all vehicles are disconnected, a request can be initiated by the RM service to create, update, or delete a SL group resource representing the vehicles connected to each other, respectively. The RM service can continuously update the membership of the SL group to reflect the vehicles involved. This SL group resource can then be used by the city to implement group-based operations on this connected vehicle, and for example, battery and passenger load levels in the vehicle can be more easily monitored.

[0226] A request may be initiated by the RM service to create, update or delete a subscription to a SL resource if / when a relationship is established, modified or torn down, respectively, between vehicles. The RM service may continuously update the subscription to reflect the IoT entities involved in the relationship and the IoT entities that should receive notifications about changes to the subscribed SL resources. For example, a subscription may be created to generate a notification if / when one of the connected vehicles requires disconnection, such as when the vehicle should disconnect and travel in its own direction based on the vehicle's current location and destination.

[0227] A request may be initiated by the RM service to create, update or delete a SL access control policy if / when a connection between vehicles is established, modified or torn down, respectively. For example, vehicles connected to each other may be granted access to each other's diagnostic information, such as battery levels.

[0228] Requests may be initiated by the RM service to configure, reconfigure, or delete scheduling policies and / or parameters for vehicles that connect and / or disconnect from each other. The schedule may reflect when vehicles connect to each other, when vehicles are scheduled to disconnect, and when vehicles should arrive at specific locations on their journeys.

[0229] oneM2M Implementation

[0230] An exemplary oneM2M embodiment of the introduced RM service functionality will be described herein. The exemplary embodiments describe one or more possible implementations of the RM service.

[0231] like Fig.10 As shown in , the RM service can be implemented as a new Common Service Function (CSF) that implements the RM service functions described herein. The RM service functions can also be implemented as capabilities of the existing oneM2M CSF.

[0232] In a oneM2M embodiment, the RM CSF may support RM policy resources, such as Fig.11 The exemplary <rmpolicy>resource. <rmpolicy>Resources can be created, updated, and deleted by the AE or CSE, or provisioned into the RM CSF using out-of-band mechanisms, such as device management. <rmpolicy>Resources may support attributes as defined in Table 4, which are based on the RM policy attribute definitions previously defined in Table 1.

[0233] Table 4 - <rmpolicy>Resource attributes

[0234]

[0235]

[0236] In a oneM2M embodiment, the RM CSF may maintain the RM state in resources, such as Fig.12 The exemplary <relationship>Resources. Can be created, updated and deleted by RM CSF when relationships are established, modified and torn down respectively. <relationship>resource. <relationship>The resource may support the attributes defined in Table 5, which are based on the RM state attribute definition defined in Table 3. <relationship>A link to a resource (e.g. relationshipLink) is added to an existing oneM2M resource to reflect the IoT entity that is a participant in the relationship (e.g. <ae> 、 <remotecse>or other IoT entities). Alternatively or additionally, to define new <relationship>A lightweight option for resources could be to add one or more relationship-centric attributes to an existing oneM2M resource. For example, one or more new attributes could be added to <ae> 、 <remotecse>Or other IoT / oneM2M resources. For other oneM2M resource types, you can define similar <relationship>Those properties defined in the resource.

[0237] Table 5 - <relationship>Resource attributes

[0238]

[0239]

[0240]

[0241] Fig.13A -B shows an exemplary oneM2M process flow in which the RM functionality described herein may be used. In this process flow, the oneM2M Interworking Proxy Entity (IPE) is used to interwork non-oneM2M devices to a server hosting the oneM2M CSE. The RM CSF manages the relationship between the interworking non-oneM2M devices and the oneM2M AE hosted on an IoT user device. Both the AE hosted on an IoT field device and the user device are registered with the CSE.

[0242] At step 0, the oneM2M interworking proxy entity (IPE) may discover non-oneM2M devices. Alternatively, non-oneM2M may discover and / or register with the IPE. During such discovery / registration, information about each individual device (e.g., type of device, location of device, reporting rate of device, functionality of device, interface of device, etc.) may be exchanged.

[0243] At step 1, oneM2M IPE can interwork non-oneM2M devices to oneM2M CSE hosted in IoT server or gateway. Non-oneM2M devices can be modeled as oneM2M resources hosted in CSE. For example, <ae> 、 <node> 、 <container> 、 <flexcontainer> 、 <contentinstance> 、 <timeseries> 、 <timeseriesinstance> 、 <schedule> 、 <group> 、 <semanticdescriptor>The oneM2M resources can be used to interwork and model non-oneM2M in CSE. Within such resources, the IPE can configure the information about the device obtained in step 0.

[0244] At step 2, the oneM2M IPE may send a request to the CSE to create a RM policy, the RM policy including rules that provide guidance to the RM CSF for the establishment, modification, and removal of relationships between interworking non-oneM2M devices that have been modeled using oneM2M resources in the CSE. The request to create the RM policy may be issued by the IPE at different times. For example, such a request may be issued when a non-oneM2M device registers or deregisters, when an AE registers with the CSE, or at some time thereafter. The request to create the RM policy may be implemented by a resource creation request. Alternatively, the RM policy including rules that provide guidance to the RM CSF for the establishment, modification, and removal of relationships between AEs may optionally be pre-provisioned into the RM CSF of the CSE. For example, the RM policy may be hard-coded into the RM CSF by the developer when the RM CSF is developed, pre-configured into the RM CSF at deployment, or configured using an out-of-band mechanism by a service provider that owns and operates the RM CSF within its service platform. Some examples of out-of-band mechanisms may include a management portal that can be used by a service provider to configure and manage its platform or a device management server, which the service provider can use to push RM policies to the RM CSF in its service platform. The rules within the RM policy may include information such as the type of relationship that applies to the policy, the RM trigger criteria that the RM CSF can use to trigger the establishment, modification and / or removal of the relationship associated with the policy, and the RM actions that the RM CSF can perform when establishing, modifying or removing the relationship associated with the policy.

[0245] At step 3, the RM CSF may collect RM contexts from metadata published by individual non-oneM2M devices that have been modeled by the IPE using oneM2M resources. The RM CSF may then analyze the RM contexts in these resources against RM trigger criteria defined within RM policies that have been created and configured within the RM CSF. Based on the RM trigger criteria defined within the RM policies, the RM CSF may determine whether any criteria have been met to trigger the establishment of a relationship between applicable interworking non-oneM2Ms. For example, if more than one non-oneM2M device uses the same type of <flexcontainer>, then the CSE can determine that there is a functional compatibility relationship between them. If more than one non-oneM2M device uses the same or similar type <semanticdescriptor>specialization, the CSE can determine that there is a functional compatibility relationship between them. <locationpolicy>resources, the CSE can determine that there is a location relationship between them. <schedule>If there are resources, the CSE may determine that there is a scheduling relationship between them. Other exemplary relationship determinations based on the relationships described herein are also possible.

[0246] At step 4, based on RM triggering criteria defined within RM policies, RM CSF may determine that a relationship may be established between interworking non-oneM2M devices, IPEs and / or AEs. RM CSF may trigger and establish a relationship of the type defined by RM policies.

[0247] At step 5, based on the RM actions defined in the RM policy, the RM CSF may implement RM actions when it establishes the relationship between the interworking non-oneM2M devices, IPEs and / or AEs involved. These RM actions may involve requests being implemented by the RM CSF on behalf of the interworking non-oneM2M devices involved in the relationship. The RM CSF may also initiate requests to other CSFs hosted in the CSE to manage the relationship. The RM CSF may initiate, for example (but not limited to), the following RM actions.

[0248] RM CSF can initiate <group>resources, and may configure interworking non-oneM2M device resources and / or AEs communicating therewith and involved in a relationship as such <group>Members of the resource.

[0249] RM CSF can initiate <subscription>Resources are created and can be configured <subscription>The notificationURI attribute of the resource is used to send notifications to one or more interworking non-oneM2M devices, their IPEs or other AEs involved in the relationship.

[0250] The RM CSF may initiate the generation and bootstrapping of credentials for the interworking non-oneM2M devices, their IPEs or other AEs involved in the relationship so that they may communicate securely with each other.

[0251] RM CSF can initiate <accesscontrolpolicy>Creation and / or configuration of resources (and / or existing <accesscontrolpolicy>resource privileges), thereby granting the AE, IPE and interworking non-oneM2M devices involved in the relationship access to each other's resources.

[0252] The RM CSF may initiate one or more oneM2M requests for resources associated with the AE, IPE and interworking non-oneM2M devices involved in the relationship.

[0253] RM CSF may initiate configuration of QoS parameters in the underlying transport network of the interworking non-oneM2M devices, IPEs and AEs involved in the connection relationship.

[0254] The RM CSF may initiate configuration of scheduling parameters of the interworking non-oneM2M devices, IPEs and AEs involved in the relationship so that their schedules may be aligned with each other in order to facilitate coordinated communication times.

[0255] At step 6, after the relationship between the interworking non-oneM2M device and the AE is established, the RM CSF may create <relationship>The RM CSF may also share the RM state with other AEs, IPEs and interworking non-oneM2M devices.

[0256] At step 7, after the relationship between the interworking non-oneM2M device and the AE, IPE is established, the RM CSF may optionally initiate notification of the relationship establishment to the interworking non-oneM2M devices, IPEs and AEs involved in the relationship and / or other interworking non-oneM2M devices, IPEs and AEs that may be interested in the relationship establishment (e.g., the AE or IPE that created the RM policy). These notifications may include <relationship>An identifier or representation of a resource (i.e., RM state).

[0257] At step 8, once the RM CSF has established the relationships between the interworking non-oneM2M devices, IPEs and AEs, the entities involved in the relationships may be given the ability to interact and communicate with each other. Such capabilities may be provided by the RM CSF creating and configuring appropriate <group> 、 <subscription> 、 <schedule>and <accesscontrolpolicy>This is accomplished by configuring resource and / or configuration credentials and underlying network QoS settings.

[0258] At step 9 , similar to step 3 , based on the RM trigger criteria defined within the RM policy, the RM CSF may evaluate the RM contexts it has collected to determine whether any criteria have been met to trigger modification of the relationships between applicable entities.

[0259] At step 10, based on RM trigger criteria defined in RM policies, RM CSF may determine that the relationship between interworking non-oneM2M devices, IPEs and / or AEs needs to be modified. RM CSF may trigger the modification of the relationship.

[0260] At step 11, similar to step 5, based on the RM actions defined in the RM policy, the RM CSF may implement actions when it modifies the relationship between the interworking non-oneM2M devices, IPEs and / or AEs involved. Such RM actions may include implementing requests by the RM CSF on behalf of those entities involved in the relationship. The RM CSF may also initiate requests to other CSFs hosted in the CSE to manage the relationship. The RM CSF may initiate, for example (but not limited to), the following RM actions.

[0261] RM CSF can initiate <group>resources and reconfigure the interworking non-oneM2M devices, IPEs and / or AEs involved in the relationship to <group>Members of the resource.

[0262] RM CSF can initiate <subscription>The resource is updated and the notificationURI attribute is reconfigured for the interworking non-oneM2M devices, IPEs and / or AEs involved in the relationship.

[0263] Before the relationship is modified, the RM CSF may initiate the revocation of credentials from the interworking non-oneM2M devices, IPEs and / or AEs involved in the relationship. The RM CSF may then initiate the generation and bootstrapping of new credentials for those entities involved in the modified relationship so that they can communicate securely with each other.

[0264] RM CSF can initiate <accesscontrolpolicy>Deletion or updating of resources or privileges defined in those resources to revoke access privileges for any interworking non-oneM2M devices, IPEs and / or AEs no longer involved in the relationship, and to grant privileges to any new entities involved in the relationship.

[0265] The RM CSF may initiate one or more requests for resources associated with the interworking non-oneM2M devices, IPEs and / or AEs involved in the modified relationship.

[0266] The RM CSF may initiate reconfiguration of QoS parameters in the underlying transport network that may connect the interworking non-oneM2M devices, IPEs and / or AEs involved in the modified relationship (as well as any entities no longer involved).

[0267] RM CSF may initiate reconfiguration of scheduling parameters of interworking non-oneM2M devices, IPEs and / or AEs (and entities no longer involved) involved in the modified relationship so that their scheduling can be aligned with each other. For example, such parameters may include sleep, communication, functional and other scheduling parameters.

[0268] At step 12, after the relationship between the interworking non-oneM2M device, IPE and / or AE is modified, the RM CSF may update the corresponding <relationship>resource.

[0269] At step 13, after the relationship between the interworking non-oneM2M device, IPE and / or AE is modified, the RM CSF may optionally initiate notification of the modified relationship to the entities involved in the relationship and / or other entities that may be interested in the relationship modification (e.g., the AE or IPE that created the RM policy). Such notification may include the updated <relationship>An identifier or representation of a resource (i.e., RM state).

[0270] At step 14, once the RM CSF modifies the relationship between the interworking non-oneM2M devices, IPEs and / or AEs involved in the relationship, the entities involved in the relationship may be given the ability to interact and communicate with each other. Such capabilities may be provided by the RM CSF updating the appropriate <group> 、 <subscription> 、 <accesscontrolpolicy>or <schedule>This can be achieved by using resources and / or credentials or underlying network QoS settings.

[0271] At step 15 , similar to step 3 , based on the RM trigger criteria defined within the RM policy, the RM CSF may evaluate the RM contexts it has collected to determine whether any RM trigger criteria are met to trigger the teardown of the relationships between applicable entities.

[0272] At step 16, based on the RM trigger criteria defined in the RM policy, the RM CSF may determine that the relationship between the interworking non-oneM2M devices, IPEs and / or AEs needs to be torn down. The RM CSF may trigger the torn down of the relationship.

[0273] At step 17, similar to step 5, based on the RM actions defined in the RM policy, the RM CSF may perform actions when it tears down the relationship between the interworking non-oneM2M devices, IPEs and / or AEs. Such RM actions may include the implementation of requests by the RMCSF on behalf of the entities involved in the relationship. The RM CSF may also initiate requests to other CSFs hosted in the CSE to manage the relationship. The RM CSF may initiate, for example (but not limited to), the following RM actions.

[0274] RM CSF can initiate <group>Deletion of resources.

[0275] RM CSF can initiate <subscription>Deletion of resources and sending notifications to indicate <subscription>The resource is deleted.

[0276] The RM CSF may initiate the revocation of credentials from entities involved in the relationship being torn down.

[0277] RM CSF may initiate the revocation of access control privileges from entities involved in the relationship being removed, either by deleting or updating <accesscontrolpolicy>resource.

[0278] The RM CSF may initiate one or more CSE requests to the entities involved in the relationship being torn down.

[0279] The RM CSF may initiate the revocation of QoS parameters in the underlying transport network that may connect the entities involved in the relationship being torn down.

[0280] RM CSF may initiate a <schedule>Resources or <schedule>Update or remove properties within a resource.

[0281] At step 18, after the relationship between the interworking non-oneM2M device, IPE and / or AE is removed, the RM CSF may update or delete the corresponding <relationship>RM status in the resource.

[0282] At step 19, after the relationship between the interworking non-oneM2M devices, IPEs and / or AEs is torn down, the RM CSF may optionally initiate a notification regarding the relationship teardown. Such notifications may be sent to entities involved in the relationship and / or other entities that may be interested in the relationship being torn down (e.g., the AE or IPE that created the RM policy). These notifications may include <relationship>An identifier or representation of a resource.

[0283] Exemplary Graphical User Interface

[0284] An RM user interface may be implemented to help users configure RM policies and receive notifications from the RM service about establishing, modifying, or tearing down relationships between IoT entities. The user interface may allow users to configure RM trigger criteria and RM actions, thereby defining the type of relationship, criteria for establishing, modifying, or tearing down a relationship, and the actions that the RM service performs when a relationship is established, modified, or torn down. The user interface may also display a list of one or more established relationships between IoT entities. For example, Fig.14 An exemplary user interface corresponding to the relationship-based smart city embodiments described herein is shown.

[0285] Example Environment

[0286] Fig.15A is an illustration of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or World Wide Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally speaking, M2M provides a building block for IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of IoT / WoT and IoT / WoT service layer, etc. Figure 2-6 , 8-10 or 13A-B, any client, proxy or server device shown in any of the Figures may include, for example, Fig.15A -D is a node of the communication system shown.

[0287] The service layer can be a functional layer within the network service architecture. The service layer is usually located above the application protocol layer such as HTTP, CoAP or MQTT, and provides value-added services for client applications. The service layer also provides an interface to the core network at the lower resource layer, such as the control layer and the transport / access layer. The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control and service clustering. Recently, several industry standard entities (such as oneM2M) have been developing the M2M service layer to address the challenges associated with integrating M2M-type devices and applications into deployments such as the Internet / World Wide Web, cellular networks, enterprise networks and home networks. The M2M service layer can provide applications and / or various devices with access to the total set or collection (which can be referred to as CSE or SCL) of the aforementioned capabilities or functions supported by the service layer. Several examples include (but are not limited to) security, charging, data management, device management, discovery, provisioning and connection management that can be used by various applications in common. These capabilities or functions are made available to such various applications by utilizing the message format, resource structure and resource representation defined by the M2M service layer. CSE or SCL is a functional entity that can be implemented by hardware and / or software, and provides (service) capabilities or functions (that is, functional interfaces between such functional entities) that are presented to various applications and / or devices to enable them to use such capabilities or functions.

[0288] like Fig.15A As shown in , the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may be composed of multiple access networks that provide content such as voice, data, video, messaging, broadcasting, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0289] like Fig.15A As shown in , the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of an end-to-end M2M deployment, and the field domain refers to the regional network that is usually behind an M2M gateway. Both the field domain and the infrastructure domain may include a variety of different nodes of the network (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a device 18. It should be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M devices 18 is configured to send and receive signals via a communication network 12 or a direct radio link using a communication circuit. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate through an operator network (such as the communication network 12) or a direct radio link. For example, the M2M devices 18 may collect data and send the data to the M2M applications 20 or other M2M devices 18 via the communication network 12 or a direct radio link. The M2M devices 18 may also receive data from the M2M applications 20 or the M2M devices 18. In addition, data and signals may be sent and received to / from the M2M applications 20 via the M2M service layer 22, as described later. The M2M devices 18 and the gateway 14 may communicate via various networks, including, for example, cellular, WLAN, WPAN (e.g., ZigBee, 6LoWPAN, Bluetooth), direct radio links, and wired networks. Exemplary M2M devices include (but are not limited to) tablet devices, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, gaming consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart sockets.

[0290] Reference Fig. 15B , the M2M service layer 22 in the illustrated field provides services for the M2M applications 20, the M2M gateways 14 and the M2M devices 18, and the communication network 12. It should be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M service layer 22 can be implemented by one or more nodes of the network, which may include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities applicable to the M2M devices 18, the M2M gateways 14, and the M2M applications 20. The functions of the M2M service layer 22 can be implemented in a variety of ways, such as as a web server, implemented in a cellular core network, implemented in the cloud, and so on.

[0291] Similar to the M2M service layer 22 shown, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12 in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateways 14 and the M2M devices 18 in the field domain. It should be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with the service layers of different service providers. The M2M service layer 22' can be implemented by one or more nodes of the network, which may include servers, computers, devices, virtual machines (such as cloud computing / storage farms, etc.), etc.

[0292] Also refer to Fig. 15B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that can be utilized by a variety of applications and verticals. Such service capabilities enable M2M applications 20 and 20' to interact with devices and implement functions such as data collection, data analysis, device management, security, accounting, service / device discovery, etc. In essence, these service capabilities free applications from the burden of implementing these functions, thereby simplifying application development and reducing the cost and time of marketing. The service layers 22 and 22' also enable M2M applications 20 and 20' to communicate through various networks (such as network 12) connected to the services provided by the service layers 22 and 22'.

[0293] The M2M applications 20 and 20' may include applications in various industries, such as (but not limited to) transportation, health care, connected home, energy management, asset tracking, and security and monitoring. As mentioned above, the M2M service layer running across the devices, gateways, servers and other nodes of the system supports functions such as data collection, device management, security, accounting, location tracking / geofencing, device / service discovery and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0294] Typically, the service layer (such as Fig. 15B The service layer 22 and 22' shown in the figure defines a software middleware layer that supports value-added service capabilities through a set of application programmer interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. The service layer of ETSI M2M is called the service capability layer (SCL). The SCL can be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer can be implemented in an M2M device (referred to as a device SCL (DSCL) therein), a gateway (referred to as a gateway SCL (GSCL) therein) and / or a network node (referred to as a network SCL (NSCL) therein). The oneM2M service layer supports a set of common service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is called a common service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The 3rd Generation Partnership Project (3GPP) also defines an architecture for machine type communication (MTC). In this architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether it is specifically implemented in the DSCL, GSCL or NSCL of the ETSI M2M architecture, specifically implemented in the service capability server (SCS) of the 3GPP MTC architecture, specifically implemented in the CSF or CSE of the oneM2M architecture, or specifically implemented in some other node of the network, an instance of the service layer can be implemented as a logical entity (such as software, computer executable instructions, etc.) executed on one or more independent nodes (including servers, computers and other computing devices or nodes) in the network, or implemented as part of one or more existing nodes. As an example, an instance of the service layer or its components can be implemented by running on a computer with the following as described below. Fig. 15C or Fig.15D It is implemented in the form of software on a network node (such as a server, computer, network, device, etc.) of the general architecture shown in .

[0295] Furthermore, the methods and functions described herein may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services.

[0296] Fig. 15C is a block diagram of an exemplary hardware / software architecture of a node of a network, such as Figure 2-6 , 8-10 or 13A-B shown in the client, server or agent, the node can be used as, for example Fig.15A and 15B The M2M server, gateway, device or other node in the M2M network shown in FIG. Fig. 15C As shown in FIG. 1 , the node 30 may include a processor 32, a non-removable memory 44, a removable memory 46, a speaker / microphone 38, a keypad 40, a display, a touchpad and / or an indicator 42, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuits, such as a transceiver 34 and a transmit / receive unit 36. It should be appreciated that the node 30 may include any sub-combination of the foregoing elements while being consistent with an embodiment. The node may be a node that implements the USF functionality described herein, such as with reference to FIG. Figure 7 , 9A -B and 13A-B, or Figure 1-6 , 8 and 10-12, Tables 1-5 or the data structures in the claims.

[0297] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer executable instructions in a memory of the memory node (e.g., memory 44 and / or memory 46) to implement various desired functions of the node. For example, the processor 32 may implement signal encoding, data processing, power control, input / output processing, and / or any other function that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run an application layer program (e.g., a browser) and / or a radio access layer (RAN) program and / or other communication programs. The processor 32 may also implement security operations, such as authentication, security key agreement, and / or cryptographic operations, at the access layer and / or application layer, for example.

[0298] like Fig. 15C As shown, the processor 32 is coupled to its communication circuit (e.g., transceiver 34 and / or transmit / receive unit 36). The processor 32 can control the communication circuit by executing computer executable instructions so that the node 30 communicates with other nodes via the network to which it is connected. Specifically, the processor 32 can control the communication circuit to implement the methods described herein (e.g., Figure 7 , 9A -B and 13A-B) and the sending and receiving steps in the claims. Fig. 15C The processor 32 and transceiver 34 are depicted as separate components, but it should be appreciated that the processor 32 and transceiver 34 may be integrated together in an electronic package or chip.

[0299] The send / receive unit 36 ​​can be configured to send or receive signals to / from other nodes, including M2M servers, gateways, devices, and the like. For example, in one embodiment, the send / receive unit 36 ​​can be an antenna configured to send and / or receive RF signals. The send / receive unit 36 ​​can support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In one embodiment, the send / receive unit 36 ​​can be, for example, a transmitter / detector configured to send and / or receive IR, UV, or visible light signals. In another embodiment, the send / receive unit 36 ​​can be configured to send and receive both RF and optical signals. It should be appreciated that the send / receive unit 36 ​​can be configured to send and / or receive any combination of wireless or wired signals.

[0300] In addition, although the transmission / reception unit 36 Fig. 15C 30 is depicted as a single unit, but the node 30 may include any number of transmit / receive units 36. More specifically, the node 30 may employ MIMO technology. Therefore, in one embodiment, the node 30 may include two or more transmit / receive units 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0301] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive unit 36 ​​and to demodulate signals received by the transmit / receive unit 36. As mentioned previously, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers to enable the node 30 to communicate, for example, via multiple RATs, such as UTRA and IEEE 802.11.

[0302] The processor 32 can access information from and store data in any type of suitable memory, such as non-removable memory 44 and / or removable memory 46. For example, the processor 32 can store the session context in its memory, as described above. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 32 can access information from and store data in a memory that is not physically located on the node 30 (such as located on a server or a home computer). The processor 32 can be configured to control the lighting mode, image, or color on the display or indicator 42.

[0303] Processor 32 may receive power from power source 48 and may be configured to distribute and / or control power to other components in node 30. Power source 48 may be any suitable device for powering node 30. By way of example, power source 48 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hybrid (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0304] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) regarding the current location of node 30. It should be appreciated that node 30 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.

[0305] The processor 32 may also be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 52 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for taking photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, and more.

[0306] Node 30 may be embodied in other devices or equipment, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothes), medical or electronic health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks), trains or airplanes. Node 30 may be connected to other components, modules or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 52.

[0307] Fig.15D is a block diagram of an exemplary computing system 90 that may also be used to implement one or more nodes of a network, such as Figure 2-6 , 8-10 or 13A-B shown in the client, server or agent, the node can be used as, for example, in Fig.15A and 15B The M2M server, gateway, device or other node in the M2M network shown in FIG.

[0308] The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may take the form of software, regardless of where or by what means such software is stored and accessed. Such computer-readable instructions may be executed within a processor, such as a central processing unit (CPU) 91, to cause the computing system 90 to perform work. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor different from the main CPU 91 that implements additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed system and method for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0309] In operation, the CPU 91 fetches, decodes and executes instructions, and transfers information to / from other resources via the computer's primary data transfer path, the system bus 80. Such a system bus connects components in the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0310] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function, thereby translating a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function, thereby isolating processes within the system and isolating system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing is set between processes, it cannot access memory within the virtual address space of another process.

[0311] Additionally, computing system 90 may include a peripheral controller 83 responsible for communicating instructions from CPU 91 to peripherals such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0312] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0313] In addition, the computing system 90 may include communication circuits, such as a network adapter 97, which may be used to connect the computing system 90 to an external communication network, such as Fig.15A -D network 12, so that the computing system 90 can communicate with other nodes of the network. Communication circuits can be used to implement the present invention independently or in combination with CPU 91 (for example, in Figure 7 , 9A -B and 13A-B) and the sending and receiving steps described in the claims.

[0314] It should be understood that any or all of the systems, methods, and processes described herein may be specifically implemented in the form of computer-readable instructions (i.e., program codes) stored on a computer-readable storage medium, which implement and / or realize the systems, methods, and processes described herein when executed by a machine (e.g., a device of an M2M network, such as an M2M server, gateway, device, etc.). Specifically, any of the steps, operations, or functions described above may be implemented in the form of such computer-readable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented with any non-transitory (i.e., tangible or physical) information storage method or technology, but such computer-readable storage media do not include signals. Computer-readable storage media include (but are not limited to) RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, tapes, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computer.

[0315] It should be understood that the implementation Figure 7 , 9A The entities of steps 13A-B and 13A-B (such as IoT devices, IoT servers, IoT gateways, IoT service layers, RM services, IoT applications, oneM2M devices, non-oneM2M devices, oneM2M IPE, AE, CSE, RMCSF, IoT user equipment, UE, etc.) can be logical entities implemented in the form of software (i.e., computer executable instructions), which is stored in a device configured for wireless and / or network communication or, for example, in Fig. 15C or Fig.15D Those shown in the memory of the computer system and executed on its processor. That is, Figure 7 , 9A -B and 13A-B may be used with a device stored in a device (e.g., Fig. 15C or Fig.15D The computer system or device shown in FIG. 1 is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. 1 , which are implemented when executed by the processor of the device. Figure 7 , 9A -B and the steps shown in 13A-B. It should also be understood that Figure 7 , 9A -B and 13A-B can be implemented as a set of virtualized network functions. The network functions do not have to communicate directly, but can communicate through forwarding or routing functions. It should also be understood that Figure 7 , 9A Any of the sending and receiving steps shown in 13A-B and 13A-B may be implemented by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed thereby.

[0316] The following is a list of abbreviations related to service layer technology that may appear in the previous description. Unless otherwise indicated, the abbreviations used in this article refer to the corresponding terms listed below:

[0317] ADN - Application Dedicated Node

[0318] AE——Application Entity

[0319] API – Application Programmer Interface

[0320] ASE – Automated Service Registration

[0321] ASE-C——Automated Service Registration Client

[0322] ASE-S——Automated Service Registration Server

[0323] ASN - Application Server Node

[0324] CSE – Common Services Entity

[0325] CSF – Common Service Function

[0326] IN – Infrastructure Network

[0327] IoT

[0328] IP – Internet Protocol

[0329] M2M – Machine to Machine

[0330] MN——Middle Node

[0331] NoDN——Non-oneM2M Node

[0332] PoA – Point of Access

[0333] RM – Relationship Management

[0334] RM Service——Relationship Management Service

[0335] ROA — Resource Oriented Architecture

[0336] SL — Service Layer

[0337] URI — Uniform Resource Identifier

[0338] This written description uses examples to disclose the invention, including the best mode, and also to enable those skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples should fall within the scope of the claims if they have elements that do not differ from the literal language of the claims or include equivalent elements that do not differ substantially from the literal language of the claims.< / relationship> < / relationship> < / schedule> < / schedule> < / accesscontrolpolicy> < / subscription> < / subscription> < / group> < / schedule> < / accesscontrolpolicy> < / subscription> < / group> < / relationship> < / relationship> < / accesscontrolpolicy> < / subscription> < / group> < / group> < / accesscontrolpolicy> < / schedule> < / subscription> < / group> < / relationship> < / relationship> < / accesscontrolpolicy> < / accesscontrolpolicy> < / subscription> < / subscription> < / group> < / group> < / schedule> < / locationpolicy> < / semanticdescriptor> < / flexcontainer> < / semanticdescriptor> < / group> < / schedule> < / timeseriesinstance> < / timeseries> < / contentinstance> < / flexcontainer> < / container> < / node> < / ae> < / relationship> < / relationship> < / remotecse> < / ae> < / relationship> < / remotecse> < / ae> < / relationship> < / relationship> < / relationship> < / relationship> < / rmpolicy> < / rmpolicy> < / rmpolicy> < / rmpolicy>

Claims

1. An apparatus comprising a processor and a memory, the apparatus being connected to a communication network, the apparatus further comprising computer executable instructions stored in the memory of the apparatus, the computer executable instructions, when executed by the processor of the apparatus, causing the apparatus to implement a service layer entity on the communication network and causing the service layer entity to: registering a first device connected to a communication network; receiving first metadata from a first device; registering a second device connected to the communication network; receiving second metadata from a second device; determining, based on first metadata received from the first device and second metadata received from the second device, a trigger condition satisfying a relationship management (RM) policy to establish a machine-to-machine (M2M) / Internet of Things (IoT) entity relationship between the first device and the second device; establishing a relationship between the first device and the second device corresponding to the trigger condition; as well as An action defined by the RM policy is implemented based on the relationship between the first device and the second device, wherein the action includes executing one or more requests on behalf of the first device or on behalf of the second device so that the first device or the second device is exempted from executing the one or more requests itself.

2. The device according to claim 1, wherein: The actions include sending requests to create, update, or delete service layer resources.

3. The device according to claim 1, wherein: The action includes sending a request to at least one of a first device and a second device.

4. The device according to claim 1, wherein: The action is determined based on the type of relationship.

5. The device according to claim 1, wherein: An action is determined based on the trigger condition being met.

6. The device according to claim 1, wherein: Relationships are defined in the RM policies.

7. The device according to claim 6, wherein: The RM policy includes pre-provisioned resources in the device.

8. The device according to claim 6, wherein: The instructions also cause the service layer entity to: A request message is received from a first device to create an RM policy, wherein the request message includes rules for managing relationships between the first device and other devices.

9. The device according to claim 1, wherein: The instructions also cause the service layer entity to: Analyzing the data of the request sent by the first device and the second device to generate the RM context; Determining that the RM context satisfies a second trigger condition; as well as A second relationship is established between the first device and the second device, wherein the second relationship corresponds to a second trigger condition.

10. The device according to claim 1, wherein: The type of relationship established is based on the triggering conditions that are met.

11. The device according to claim 1, wherein: The type of relationship includes at least one of the following: a location relationship, an information sharing relationship, a master / slave relationship, a control relationship, a scheduling relationship, and a semantics-based relationship.

12. The device according to claim 1, wherein: The first apparatus comprises a oneM2M device and the second apparatus comprises a non-oneM2M device.

13. The device according to claim 1, wherein: Establishing the relationship includes: A resource including state information of the relationship is generated and stored.

14. A method, comprising, at a service layer entity: registering a first device; receiving first metadata from a first device; registering a second device; receiving second metadata from a second device; Based on the first metadata and the second metadata, determining a trigger condition satisfying a relationship management (RM) policy to establish a machine-to-machine (M2M) / Internet of Things (IoT) entity relationship between the first device and the second device; establishing a relationship between the first device and the second device corresponding to the trigger condition; as well as An action defined by the RM policy is implemented based on the relationship between the first device and the second device, wherein the action includes executing one or more requests on behalf of the first device or on behalf of the second device so that the first device or the second device is exempted from executing the one or more requests itself.

15. The method according to claim 14, wherein: RM policies are implemented as resources of service layer entities.

16. The method according to claim 14, further comprising: Create service layer entity resources to store state information about the relationship; determining an updated RM context between the first device and the second device; as well as The stored state information is modified based on the updated RM context.

17. The method according to claim 16, further comprising: Determining that the updated RM context does not satisfy the trigger condition; as well as The relationship is torn down based on that the updated RM context does not satisfy the trigger condition.

18. The method according to claim 16, further comprising: determining that the updated RM context satisfies a second trigger condition so as to modify the relationship; as well as The relationship is modified based on a second trigger condition.

19. The method according to claim 14, further comprising: Based on the relationship, a request is sent to trigger the first device to register with the service provider.

20. The method of claim 14, further comprising: Based on the relationship, a request is initiated on behalf of the first device to create, retrieve, update, or delete one or more resources hosted on the service layer entity.

21. A computer-readable storage medium comprising computer-executable instructions which, when executed by a processor, cause the processor to implement a service layer entity and cause the service layer entity to: registering a first device; receiving first metadata from a first device; registering a second device; receiving second metadata from a second device; determining, based on first metadata received from the first device and second metadata received from the second device, a trigger condition satisfying a relationship management (RM) policy to establish a machine-to-machine (M2M) / Internet of Things (IoT) entity relationship between the first device and the second device; establishing a relationship between the first device and the second device corresponding to the trigger condition; as well as An action defined by the RM policy is implemented based on the relationship between the first device and the second device, wherein the action includes executing one or more requests on behalf of the first device or on behalf of the second device so that the first device or the second device is exempted from executing the one or more requests itself.

22. The computer-readable storage medium of claim 21, wherein: The instructions also cause the service layer entity to: A request is initiated to configure a quality of service (QoS) policy or parameter in an underlying communication network connecting a first device to a second device.

23. The computer-readable storage medium of claim 21, wherein: The RM context includes one or more of the following: manufacturer information; product profile information; interface definition; service layer meta-information; capability information; the state of one or more resources; the state of one or more attributes; location information; availability scheduling; activity scheduling; semantic information; agent device information; route information; and sequence information.

24. The computer-readable storage medium of claim 21, wherein: The type and triggering conditions of the relationship are defined in one or more RM policies.

Images