IDENTIFIERS

Field of the Disclosure

[0001 ] The present disclosure relates to a method for operation of a Machine- to-Machine (M2M) network.

Background

[0002] The Internet of Things (loT) is a term used to describe a network of physical objects that includes network connectivity allowing these objects to collect and exchange data. The loT allows objects to be sensed and/or controlled remotely. Depending on the application, these objects may use some type of Machine-to-Machine Communication (M2M). Applications may be defined that operate on the objects to sense, collate, and/or report data. One way to structure such a network and applications is a resource-based

architecture. In a resource-based architecture in the loT, any resource that gets created procedurally is allocated an identity. This identity typically has a lifetime equivalent to that of the resource. So if the resource is deleted, or de-registered, depending on the resource type, the identity is deleted as well.

[0003] Resources can be deleted or de-registered for various reasons. Some reasons are graceful, i.e., there is time and opportunity to perform any steps needed during such a deletion. Other reasons may be ungraceful such as a power cycle of the M2M node or the M2M application interacting with it or even if an M2M node has to remove some records due to scarce resources.

[0004] There are two types of identifiers that can be allocated to a resource in a resource-based system: a temporary identifier and a permanent or global identifier. A temporary identifier is cleared when the resource is removed from the system. If the same resource is recreated, it will get a new temporary identifier, or at least there are no guarantees that it will get back the previous temporary identifier. On the other hand, a permanent identifier allocated to a resource will be tied to the resource regardless of deregistration or record deletion. [0005] In some systems, only temporary identifiers are available for some types of resources. In some systems, the requirements for maintaining permanent identifiers may be prohibitive; especially for a large number of objects. However, there are drawbacks to the use of temporary identifiers that may create additional complexity or complications. Therefore, systems and methods for group management in an M2M network are needed to deal with these

complexities.

Summary

[0006] Systems and methods for group management in a Machine-to- Machine (M2M) network are provided. In some embodiments, a method of operation of a node in an M2M network includes receiving an indication that a first temporary identifier associated with an Application Entity (AE) is a member of a first group. The method further includes determining a second node in the M2M network associated with the AE for validating the first temporary identifier associated with the AE; and validating the first temporary identifier associated with the AE by querying the second node.

[0007] In some embodiments, the node is a Group Management Server. In some embodiments, the second node is a Middle Node Common Service Entity (MN-CSE); determining the second node associated with the AE includes interacting with an Infrastructure Node Common Service Entity (IN-CSE) to identify the MN-CSE associated with the first temporary identifier; and validating the first temporary identifier includes validating the first temporary identifier associated with the AE by querying the MN-CSE. In some embodiments, the M2M network is oneM2M compliant.

[0008] In some embodiments, a method of operation of a node in an M2M network includes allocating a first temporary identifier for an AE and receiving a validation request message including the first temporary identifier for the AE and one or more groups affiliated with the AE. The method further includes, in response to receiving the validation request message, maintaining a binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE; and, in response to receiving an indication that the AE is deregistered, updating a service subscription profile for the AE at a second node to include the existing binding for the AE.

[0009] In some embodiments, prior to allocating the first temporary identifier, the method also includes receiving a registration from the AE and obtaining the service subscription profile for the AE from the second node.

[0010] In some embodiments, the method also includes receiving a second registration from the AE and obtaining the service subscription profile for the AE from the second node. The method also includes allocating a second temporary identifier for the AE; and, for each group that the service subscription profile for the AE indicates that the AE is a member, adding the second temporary identifier as a member of the group.

[0011] In some embodiments, for each group that the service subscription profile for the AE indicates that the AE is a member, the method also includes removing the first temporary identifier as a member of the group.

[0012] In some embodiments, the method also includes receiving a second registration from the AE; obtaining the service subscription profile for the AE from the second node; and allocating the first temporary identifier for the AE to the AE.

[0013] In some embodiments, maintaining the binding includes creating the binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE. In some embodiments, maintaining the binding includes updating the binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE.

[0014] In some embodiments, the node is a MN-CSE. In some embodiments, the second node is an IN-CSE; obtaining the service subscription profile includes obtaining the service subscription profile for the AE from the IN-CSE; and updating the service subscription profile includes updating the service

subscription profile for the AE at the IN-CSE to include the binding.

[0015] In some embodiments, the M2M network is oneM2M compliant.

[0016] In some embodiments, a method of operation of a node in an M2M network includes receiving an update for a service subscription profile for an AE including a binding. The binding includes a first temporary identifier associated with the AE and one or more groups affiliated with the AE. The method also includes storing the binding.

[0017] In some embodiments, the binding also includes a second node associated with the AE for validating the first temporary identifier associated with the AE. In some embodiments, the method also includes receiving a request, from a third node, for a second node in the M2M network associated with the AE for validating the first temporary identifier associated with the AE and responding with the second node associated with the AE.

[0018] In some embodiments, the method also includes receiving a request, from a second node, for the binding and responding with the binding. In some embodiments, the node is an IN-CSE, the second node is a MN-CSE, and the third node is a Group Management Server. In some embodiments, the M2M network is oneM2M compliant.

[0019] In some embodiments, a method of operation of an M2M network includes receiving, by a MN-CSE, a registration from an AE; obtaining, by the MN-CSE, a service subscription profile for the AE from an IN-CSE; allocating, by the MN-CSE, a first temporary identifier for the AE; receiving, by a Group

Management Server, an indication that the first temporary identifier associated with the AE is a member of a first group; interacting, by the Group Management Server, with the IN-CSE, to identify the MN-CSE associated with the first temporary identifier; validating, by the Group Management Server, the first temporary identifier associated with the AE by querying the MN-CSE; receiving, by the MN-CSE, a validation request message including the first temporary identifier for the AE and the groups affiliated with the AE; in response to receiving the validation request message, maintaining, by the MN-CSE, a binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE; in response to receiving, by the MN-CSE, an indication that the AE is deregistered, updating, by the MN-CSE, the service subscription profile for the AE at the IN-CSE to include the binding; receiving, by the IN-CSE, the update for the service subscription profile for the AE including the binding; and storing, by the IN-CSE, the binding. The binding includes the first temporary identifier for the AE; the MN-CSE associated with the AE; and the one or more groups affiliated with the AE.

[0020] In some embodiments, a node in an M2M network includes a communication interface configured to communicatively couple the node to the M2M network and circuitry. The circuitry is configured to: receive an indication that a first temporary identifier associated with an AE is a member of a first group; determine a second node in the M2M network associated with the AE for validating the first temporary identifier associated with the AE; and validate the first temporary identifier associated with the AE by querying the second node.

[0021 ] In some embodiments, a node in an M2M network includes a communication interface configured to communicatively couple the node to the M2M network and circuitry. The circuitry is configured to: allocate a first temporary identifier for an AE; receive a validation request message including the first temporary identifier for the AE and one or more groups affiliated with the AE; in response to receiving the validation request message, maintain a binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE; and in response to receiving an indication that the AE is deregistered, update a service subscription profile for the AE at a second node to include the binding.

[0022] In some embodiments, a node in an M2M network includes a communication interface configured to communicatively couple the node to the M2M network and circuitry. The circuitry is configured to: receive an update for a service subscription profile for an AE including a binding and storing the binding. The binding includes a first temporary identifier associated with the AE and one or more groups affiliated with the AE.

[0023] In some embodiments, a node in an M2M network includes a receiving module operative to receive an indication that a first temporary identifier associated with an AE is a member of a first group; a determination module operative to determine a second node in the M2M network associated with the AE for validating the first temporary identifier associated with the AE and validate the first temporary identifier associated with the AE by querying the second node.

[0024] In some embodiments, a node in an M2M network includes an identifier allocation module operative to allocate a first temporary identifier for an AE; a receiving module operative to receive a validation request message including the first temporary identifier for the AE and one or more groups affiliated with the AE; a binding module operative to, in response to receiving the validation request message, maintain a binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE; and an update module operative to, in response to receiving an indication that the AE is deregistered, update a service subscription profile for the AE at a second node to include the binding.

[0025] In some embodiments, a node in an M2M network includes a receiving module operative to receive an update for a service subscription profile for an AE including a binding and a storage module operative to store the binding.

[0026] In some embodiments, a node in an M2M network is adapted to:

receive an indication that a first temporary identifier associated with an AE is a member of a first group; determine a second node in the M2M network

associated with the AE for validating the first temporary identifier associated with the AE; and validate the first temporary identifier associated with the AE by querying the second node.

[0027] In some embodiments, a computer program includes instructions which, when executed on at least one processor, cause the at least one processor to carry out a method disclosed herein. In some embodiments, a carrier contains the computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0028] Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures. Brief Description of the Drawing Figures

[0029] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0030] Figure 1 illustrates an example communication flow in an Machine-to- Machine (M2M) network;

[0031] Figure 2 illustrates an example communication flow in an M2M network with Middles Nodes (MNs) and Infrastructure Nodes (INs);

[0032] Figure 3 is a flow chart illustrating the operation of a node in an M2M network (e.g., a Group Management Server) for validating a temporary identifier associated with an Application Entity (AE) according to some embodiments of the present disclosure;

[0033] Figure 4 is a flow chart illustrating the operation of a node in an M2M network (e.g., a Middle Node Common Service Entity (MN-CSE)) for maintaining a binding for an AE according to some embodiments of the present disclosure;

[0034] Figure 5 is a flow chart illustrating the operation of a node in an M2M network (e.g., an Infrastructure Node Common Service Entity (IN-CSE)) for storing a binding for an AE according to some embodiments of the present disclosure;

[0035] Figure 6 is a flow chart illustrating the operation of an M2M network (e.g., a oneM2M network) for maintaining a binding for an AE according to some embodiments of the present disclosure;

[0036] Figure 7 is a flow chart illustrating the operation of an M2M network (e.g., a oneM2M network) for updating group membership for an AE according to some embodiments of the present disclosure;

[0037] Figure 8 is a block diagram of a node in an M2M network (e.g., a Group Management Server, MN-CSE, or IN-CSE) according to some other embodiments of the present disclosure;

[0038] Figure 9 is a block diagram of a node in an M2M network (e.g., a Group Management Server) with modules according to some embodiments of the present disclosure; [0039] Figure 10 is a block diagram of a node in an M2M network (e.g., an MN-CSE) with modules according to some embodiments of the present disclosure; and

[0040] Figure 1 1 is a block diagram of a node in an M2M network (e.g., an IN- CSE) with modules according to some embodiments of the present disclosure.

Detailed Description

[0041 ] The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following

description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

[0042] In a resource-based architecture in the Internet of Things (loT), or more generally in a Machine-to-Machine Communication (M2M) network, any resource that gets created procedurally is allocated an identity. There are two types of identifiers that can be allocated to a resource in a resource-based system: a temporary identifier and a permanent or global identifier. A temporary identifier is cleared when the resource is removed from the system. If the same resource is recreated, it will get a new temporary identifier, or at least there are no guarantees that it will get back the previous temporary identifier. On the other hand, a permanent identifier allocated to a resource will be tied to the resource regardless of deregistration or record deletion.

[0043] In some systems, only temporary identifiers are available for some types of resources. In some systems, the requirements for maintaining permanent identifiers may be prohibitive; especially for a large number of objects. However, there are drawbacks to the use of temporary identifiers that may create additional complexity or complications. [0044] One of the issues resulting from the use of temporary identifiers is that these identifiers can be members of multiple groups. Hence, when a resource de-registers or any of the conditions described above occur, and the resource reregisters with a new identifier, the old membership in any group becomes useless, and the resource is no longer a member in the groups.

[0045] The scale of this issue becomes more important when there are thousands of applications in one or more groups, leading to lost transactions for Application Entities (AEs) that had their temporary identifiers changed. In addition, it is extremely difficult to efficiently identify the AEs that experienced issues amongst all these members without specialized tools and capabilities.

[0046] While all AEs could avoid this problem by using permanent identifiers, there may be a high overhead associated with those as there is a need to ensure system-wide uniqueness of allocated identities. In addition, M2M applications may also be impacted as they would have to indicate their desire to acquire permanent identifiers, which may be an extra complexity to applications where the default is a temporary identifier. Also, the system has to keep track of all those permanent identifiers and the bindings to the proper AEs. For a system that can have thousands of applications and thousands of nodes, this may not be feasible. This is one reason why temporary identifiers were introduced in the first place.

[0047] Therefore, systems and methods for group management in an M2M network are provided. In some embodiments, a method of operation of a node in an M2M network includes receiving an indication that a first temporary identifier associated with an AE is a member of a first group. The method further includes determining a second node in the M2M network associated with the AE for validating the first temporary identifier associated with the AE; and validating the first temporary identifier associated with the AE by querying the second node.

[0048] In some embodiments, a method of operation of a node in an M2M network includes allocating a first temporary identifier for an AE and receiving a validation request message including the first temporary identifier for the AE and one or more groups affiliated with the AE. The method further includes, in response to receiving the validation request message, maintaining a binding between the first temporary identifier for the AE, the AE, and the one or more groups affiliated with the AE; and, in response to receiving an indication that the AE is deregistered, updating a service subscription profile for the AE at a second node to include the binding.

[0049] In some embodiments, a method of operation of a node in an M2M, network includes receiving an update for a service subscription profile for an AE including a binding. The binding includes a first temporary identifier associated with the AE and one or more groups affiliated with the AE. The method also includes storing the binding.

[0050] According to some embodiments, these systems and methods facilitate group management for members whose identifiers are temporary in a transparent fashion with a network-based solution not requiring any intervention. Also, the solution impacts only AEs who are members in one or more groups, hence it does scale up while allowing AEs not to be concerned with IDs at all. Additionally, these systems and methods apply to any resource-based loT system having logical nodes performing the same behavior as the nodes described herein.

[0051 ] The oneM2M system is an exemplary M2M network that includes such temporary identifier behavior as described above. oneM2M is a resource-based system and uses web protocols to identify resources. Many examples and discussions herein use oneM2M terminology and organization. However, the current disclosure is not limited thereto. These systems and methods could also be used in any other M2M network. For additional details regarding the oneM2M system, the reader is directed to the oneM2M Technical Specification (TS) for "Functional Architecture," TS-0001 . The most current version is version 1 .6.1 adopted on 30 January 2015. A version of this TS is also available from the European Telecommunications Standards Institute (ETSI) as ETSI TS 1 18 101 V1 .0.0.

[0052] Figure 1 illustrates an example communication flow in an M2M network 10. As shown in Figure 1 , M2M network 10 is divided into a Field Domain 12 and an Infrastructure Domain 14. The Field Domain 12 may include M2M Devices, M2M Gateways, Sensing and Actuation Equipment, and M2M Area Networks. The Infrastructure Domain 14 may include Application Infrastructure such as equipment (e.g., physical computers/servers of the M2M Application Service Provider) that manages data and executes coordination functions of M2M

Application Services. The Infrastructure Domain 14 may also include M2M Service Infrastructure which, among other tasks, may communicate with other M2M Service Infrastructures. One example of this is shown in Figure 1 where a connection is made to an Infrastructure Domain of another service provider.

[0053] In this example M2M network 10, the Field Domain 12 includes at least one AE 16-1 (referred to herein as AE 16 or AEs 16), at least one Common Service Entity (CSE) 18-1 (referred to herein as CSE 18 or CSEs 18), and at least one Network Service Entity (NSE) 20-1 (referred to herein as NSE 20 or NSEs 20). In some embodiments, the AE 16 contains the application logic of the M2M solution. In some embodiments, the CSE 18 contains a set of common service functions that are common to a broad range of M2M environments.

These common service functions can be mandatory or optional and may contain sub-functions. In some embodiments, the NSE 20 provides network services to the CSE 18, like device triggering, device management support, and location services. These services are related to the underlying network capabilities.

Figure 1 also shows that the Infrastructure Domain 14 of the M2M network 10 also includes an AE 16-2, a CSE 18-2, and a NSE 20-2 that perform the same functions as described above.

[0054] As shown in Figure 1 , various connections are available for the nodes in M2M network 10. As used herein, a node refers to a logical separation of services or functions. However, in some embodiments, more than one logical node may be physically co-located. The interface point between the AE 16 and the CSE 18 is referred to as the Mca point. The Mca point provides the M2M applications access to the common services included in the CSE 18. The AE 16 and CSE 18 may be co-located in the same physical entity or not. Mcc is the reference point between two CSEs 18. The Mcc reference point shall allow a CSE 18 to use the services of another CSE 18. Accordingly, the Mcc reference point between two CSEs 18 may be supported over different M2M physical entities. The services offered via the Mcc reference point are dependent on the functionality supported by the CSEs 18. Men is the reference point between a CSE 18 and the NSE 20. The Men reference point shall allow a CSE 18 to use the services (other than transport and connectivity services) provided by the NSE 20. Mcc' is the interface between two M2M service providers. In some embodiments, Mcc' is as similar as possible to the Mcc reference point.

However, due to the nature of inter-M2M communications, some differences are possible.

[0055] Figure 2 illustrates additional details of M2M network 10 with an Infrastructure Node (IN) 22 (referred to herein as IN 22 or INs 22) and Middle Nodes (MNs) 24-1 and 24-2 (referred to herein as MN 24 or MNs 24). The illustration neither constrains the multiplicity of the entities nor requires that all relationships shown are present in all embodiments. As illustrated, a dashed box behind a solid box indicates one or more AEs 16 at that location. A dashed box behind another dashed box indicates zero or more AEs 16 at that location. The NSEs 20 are not shown in Figure 2; however, the reference points Men are shown where appropriate.

[0056] Nodes are logical entities that are individually identifiable in the M2M network 10 (e.g., a oneM2M System). A CSE-Capable Node is a logical entity that contains at least one CSE 18 and contains zero or more AEs 16. The Application Service Nodes (ASNs) 26-1 and 26-2, INs 22, and MNs 24 are examples of CSE-Capable Nodes. A Non-CSE-Capable Node is a logical entity that does not contain a CSE 18 and contains one or more AEs 16. The

Application Dedicated Nodes (ADNs) 28-1 and 28-2. Non-oneM2M Device Nodes (NoDNs) 30-1 through 30-5 are examples of Non-CSE-Capable Nodes that in this case include Zero AEs.

[0057] In some embodiments, an ASN 26 is a node that contains one CSE 18 and contains at least one AE 16. There may be zero or more ASNs 26 in the Field Domain 12 of the M2M network 10. The CSE 18 in an ASN 26 communicates over the Mcc reference point with one CSE 18 residing in a MN 24 or in an IN 22. An AE 16 in an ASN 26 communicates over the Mca reference point with the CSE 18 residing in the same ASN 26. An ASN 26 communicates over Men with NSEs 20 (not shown). In some embodiments, an ASN 26 resides in an M2M Device.

[0058] In some embodiments, an ADN 28 is a node that contains at least one AE 16 and does not contain a CSE 18. There may be zero or more ADNs 28 in the Field Domain 12 of the M2M network 10. An AE 16 in the ADN 28

communicates over the Mca reference point with a CSE 18 residing in a MN 24 or in an IN 22. In some embodiments, an ADN 28 resides in a constrained M2M Device (e.g., the device may have less memory or processing resources).

[0059] In some embodiments, a MN 24 is a node that contains one CSE 18 and contains zero or more AEs 16. There may be zero or more MNs 24 in the Field Domain 12 of the M2M network 10. The CSE 18 in a MN 24 communicates over the Mcc reference point with one CSE 18 residing in a MN 24 or in an IN 22 and with one or more other CSEs 18 residing in MNs 24 or in ASNs 26. In addition, the CSE 18 in the MN 24 can communicate over the Mca reference point with AEs 16 residing in the same MN 24 or residing in an ADN 28. A CSE 18 in a MN 24 communicates over Men with NSEs 20 (not shown). In some embodiments, a MN 24 could reside in an M2M Gateway.

[0060] In some embodiments, an IN 22 is a node that contains one CSE 18 and contains zero or more AEs 16. There is exactly one IN 22 in the

Infrastructure Domain 14 per M2M service provider. A CSE 18 in an IN 22 may contain functions not applicable to other node types. The CSE 18 in the IN 22 communicates over the Mcc reference point with one or more CSEs 18 residing in MNs 24 and/or ASNs 26. The CSE 18 in the IN 22 communicates over the Mca reference point with one or more AEs 16 residing in the same IN 22 or residing in an ADN 28. The CSE 18 in the IN 22 communicates over the Men reference point with NSEs 20 (not shown), and over the Mcc' reference point with CSEs 18 residing in the INs 22 of other M2M service providers (not shown). In some embodiments, an IN 22 could reside in an M2M Service Infrastructure. [0061 ] As discussed above, two types of M2M identifiers are specified in a oneM2M environment; first, a permanent identifier where the AE identifier is system-wide and does not change regardless of where the AE 16 is instantiated; second, a temporary identifier in which an AE 16 is allocated an identifier which has only local significance within an MN-CSE (e.g., a CSE 18 in a MN 24) with whom the AE 16 is currently registered. In some M2M networks (e.g., a oneM2M system), only AE 16 resources will have the option of being allocated a temporary or permanent identifier. Other resources may only have an option to receive a temporary identifier. For example, all resources besides AEs 16 in a oneM2M system are allocated temporary identifiers only.

[0062] As discussed above, an effect of AE identifiers/M2M identifiers with local significance is that if the AE 16 deregisters and re-registers again, the AE 16 can potentially acquire a new temporary identifier. One of the issues resulting from temporary identifiers lies in that the temporary identifier of an AE 16 can be members of multiple groups. Hence, when an AE 16 de-registers or any of the conditions described above occur, and then the AE 16 re-registers with a new temporary identifier, the old membership in any group the AE 16 was a member of becomes useless and the AE 16 is no longer a member in the groups.

[0063] The scale of this issue becomes more important when there are thousands of applications in one or more groups, leading to lost transactions for AEs 16 that had their temporary identifiers changed. In addition, it may be difficult to efficiently identify the AEs 16 that experienced issues amongst all these members without specialized tools and capabilities.

[0064] Figures 3 through 5 illustrate flow charts for providing group

management in an M2M network (e.g., M2M network 10) that uses temporary identifiers. Figures 6 and 7 illustrate an exemplary interaction between several nodes in an M2M network performing functions similar to those described in Figures 3 through 5.

[0065] Figure 3 is a flow chart illustrating the operation of a node in an M2M network (e.g., a Group Management Server 32) for validating a temporary identifier associated with an AE 16 according to some embodiments of the present disclosure. While the following description refers to the Group

Management Server 32, these actions could be performed by any suitable node in the M2M network 10 The Group Management Server 32 may be implemented as a common services function in a CSE 18 in the M2M network 10. The Group Management Server 32 may also be implemented in any other suitable manner or physically co-located with any appropriate node. As illustrated in Figure 3, the Group Management Server 32 receives an indication that a first temporary identifier associated with an AE 16 is a member of a first group (step 100). The Group Management Server 32 then determines a second node in the M2M network 10 associated with the AE 16 for validating the first temporary identifier associated with the AE 16 (step 102). In some embodiments, the second node is an MN-CSE 34 (i.e., a CSE 18 located in a MN 24). Also in some embodiments, determining the second node associated with the AE 16 includes interacting with an IN-CSE 36 (i.e., a CSE 18 located in an IN 22) to identify the MN-CSE 34 associated with the first temporary identifier. The Group Management Server 32 then validates the first temporary identifier associated with the AE 16 by querying the second node (step 104).

[0066] Figure 4 is a flow chart illustrating the operation of a node in an M2M network (e.g., a MN-CSE 34) for maintaining a binding for an AE 16 according to some embodiments of the present disclosure. While the following description refers to a MN-CSE 34, these actions could be performed by any suitable node in the M2M network 10. First, the MN-CSE 34 optionally receives a registration from an AE 16 (step 200). The MN-CSE 34 then optionally obtains a service subscription profile for the AE 16 from a second node (step 202). In some embodiments, the second node is an IN-CSE 36 and obtaining the service subscription profile includes obtaining the service subscription profile for the AE 16 from the IN-CSE 36. The MN-CSE 34 then allocates a first temporary identifier for the AE 16 (step 204).

[0067] At some later point in time after the AE 16 has been added to one or more groups, the MN-CSE 34 receives a validation request message including the first temporary identifier for the AE 16 and one or more groups affiliated with the AE 16 (step 206). In some embodiments, the validation request message is received from Group Management Server 32. In response to receiving the validation request message, the MN-CSE 34 maintains a binding between the first temporary identifier for the AE 16, the AE 16, and the one or more groups affiliated with the AE 16 (step 208). If a binding did not exist before this maintaining step, the MN-CSE 34 creates the binding. If a binding did already exist, the MN-CSE 34 then updates the binding according to the information included in the validation request message.

[0068] At some later point in time, in response to receiving an indication that the AE 16 is deregistered, the MN-CSE 34 updates the service subscription profile for the AE 16 at the second node to include the binding (step 210). As discussed above, this deregistration may be graceful or ungraceful. In addition, the indication may come from any suitable node and may depend on how and/or why the AE 16 became deregistered.

[0069] Again at some later point in time, the MN-CSE 34 optionally receives a second registration from the AE 16 (step 212). Under the registration schemes without the systems and methods of the current disclosure, the AE 16 would be allocated a new temporary identifier, and the previous group membership information would be lost. Instead, the MN-CSE 34 obtains the service subscription profile for the AE 16 from the second node as discussed above in relation to step 202 (step 214).

[0070] At this point, the MN-CSE 34 may perform one of two procedures depending on the embodiment and implementation details. The MN-CSE 34 may allocate a second temporary identifier for the AE 16 (step 216A). Then, since the MN-CSE 34 has a binding that includes the previous temporary identifier for the AE 16 and the one or more groups affiliated with the AE 16, the MN-CSE 34 can update the group membership to reflect the change from the first temporary identifier to the new second temporary identifier. In some embodiments, this is accomplished by, for each group that the service subscription profile for the AE 16 indicates that the AE 16 is a member, adding the second temporary identifier as a member of the group (step 218). In this way, the AE 16, even with a new second temporary identifier, is still included as a member of the one or more groups that the AE 16 was affiliated with before the deregistration. In addition to this step of adding the second temporary identifier the MN-CSE 34 may also optionally remove the first temporary identifier from each of the groups (step 220). In some implementations, this may not be necessary. In other implementations, this may enable the more efficient use of resources.

[0071 ] In some embodiments, instead of allocating a second temporary identifier for the AE 16, the MN-CSE 34 may instead allocate the first temporary identifier for the AE 16 to the AE 16 (step 216B). In this way, the group membership information does not need to be updated since the previous entries indicating that the first temporary identifier was a member of a group will still apply to the AE 16. In this implementation, the binding may not be required to store the one or more groups affiliated with the AE 16. However, depending on the implementation of the MN-CSE 34 and/or the M2M network 10, this reallocation of the old temporary identifier may not be an option.

[0072] Figure 5 is a flow chart illustrating the operation of a node in an M2M network (e.g., an IN-CSE 36) for storing a binding for an AE 16 according to some embodiments of the present disclosure. While the following description refers to an IN-CSE 36, these actions could be performed by any suitable node in the M2M network 10. First, the IN-CSE 36 receives an update for a service subscription profile for the AE 16 including a binding (step 300). The binding includes a first temporary identifier associated with the AE 16 and one or more groups affiliated with the AE 16. In some embodiments, this update is sent by the MN-CSE 34. The IN-CSE 36 the stores the binding (step 302). If the binding did not previously exist, the IN-CSE 36 creates the binding. If the binding did previously exist, the IN-CSE 36 updates the binding.

[0073] The IN-CSE 36 may also receive a request for a second node in the M2M network 10 associated with the AE 16 for validating the first temporary identifier associated with the AE 16 (step 304). In some embodiments, this request is from Group Management Server 32. In the some embodiments, the second node is the MN-CSE 34 associated with the AE 16. The IN-CSE 36 responds with the second node associated with the AE 16 (step 306).

[0074] The IN-CSE 36 may also receive a request for the binding it has stored for the AE 16 (step 308). In some embodiments, this request is from the MN- CSE 34. The IN-CSE 36 then responds with the binding for the AE 16 (step 310). This storage of the binding and ability to have the binding later retrieved enables the system to maintain the group membership for the AE 16 even after being deregistered.

[0075] Figure 6 is a flow chart illustrating the operation of an M2M network 10 (e.g., a oneM2M network) for maintaining a binding for an AE 16 according to some embodiments of the present disclosure. Many of the steps shown in Figure 6 have corresponding steps in the flow charts shown in Figures 3 through 5. In these cases, any discussion of those steps in the previous figures is also applicable to embodiments of the steps included in Figure 6. Additionally, some details of the steps in Figure 6 are omitted for conciseness when the details are readily understood. First, the AE 16 registers with the MN-CSE 34 (step 400). The MN-CSE 34 fetches the profile from the IN-CSE 36, locates the applicable rule for verification purposes, and then allocates a temporary identifier for the AE 16 illustrated as "C1 " (step 402). This step implies that no information was found in the fetched profile that indicates any prior registrations or group membership information. The MN-CSE 34 responds to the AE 16 with the allocated temporary identifier C1 and any other necessary information (step 404).

[0076] At this point in time, the AE 16 may function in any way as part of the M2M network 10 including, for example, providing data for processing, collating data, or reporting data to other nodes. Some action results in the temporary identifier C1 being selected to be a member of Groupl (step 406). If the AE 16 has a temporary identifier, the Group Management Server 32 queries the MN- CSE 34 associated with the AE 16 (step 408). In some embodiments, the Group Management Server 32 may query the IN-CSE 36 to locate the MN-CSE 34 associated with the AE 16. In some embodiments, the query takes the form of a verification message (or validation request message) being sent to the MN-CSE 34 that includes the temporary identifier C1 and an indication that this temporary identifier has been added to Groupl (step 410). The MN-CSE 34 is able to verify that this temporary identifier belongs to an AE 16 associated with the MN-CSE 34. If this AE 16 is verified, then the MN-CSE 34 binds the temporary identifier C1 to Groupl (step 412). The MN-CSE 34 then sends the response to the Group Management Server 32 (step 414).

[0077] Now, as an example, some action resulted in the temporary identifier C1 being selected to be a member of Group2 (step 416). If the AE 16 has a temporary identifier, the Group Management Server 32 queries the MN-CSE 34 associated with the AE 16 (step 418). In some embodiments, the query takes the form of a verification message (or validation request message) being sent to the MN-CSE 34 that includes the temporary identifier C1 and an indication that this temporary identifier has been added to Group2 (step 420). The MN-CSE 34 is able to verify that this temporary identifier belongs to an AE 16 associated with the MN-CSE 34. If this AE 16 is verified, then the MN-CSE 34 binds the temporary identifier C1 to Groupl and Group2 (step 422). The MN-CSE 34 then sends the response to the Group Management Server 32 (step 424).

[0078] The AE 16 becomes deregistered, perhaps by being power cycled or having the record deleted (step 426). The MN-CSE 34 then sends a request to the IN-CSE 36 including an update to the service subscription profile by coupling the applicable rule associated with the registration used for the App-ID with information including the groups associated with the AE 16, the temporary identifier C1 , and the AE 16 (step 428). The IN-CSE 36 responds to the MN- CSE 34 and possibly the AE 16 (step 430). In some embodiments, this response may include an indication of whether or not the service subscription profile was successfully updated. The IN-CSE 36 now has a stored association between the temporary identifier C1 and the one or more groups associated with that AE 16.

[0079] Figure 7 is a flow chart illustrating the operation of an M2M network 10 (e.g., a oneM2M network) for updating group membership for an AE 16 according to some embodiments of the present disclosure. First, the AE 16 registers with the MN-CSE 34 (step 500). The MN-CSE 34 fetches the profile from the IN-CSE 36, locates the applicable rule for verification purposes and then allocates a temporary identifier for the AE 16 illustrated as "C2" (step 502). This step implies that information was found in the fetched profile that indicates a prior registration and group membership information. The MN-CSE 34 then fetches the groups associated with the registered AE 16 (step 504). In some

embodiments, this includes obtaining the list of groups from a binding stored in the profile.

[0080] The MN-CSE 34 now sends an update to the Group Management Server 32 indicating a first group, the previously used temporary identifier C1 , and the new temporary identifier C2 (step 506). In some embodiments, this is accomplished by two separate steps, adding the new temporary identifier to the group, and removing the old temporary identifier from the group. Also, although only one group update is shown in Figure 7, the current disclosure is not limited thereto. The Group Management Server 32 responds to the update (step 508). If the update is successful, the MN-CSE 34 binds the new temporary identifier C2 to Groupl and removes C1 (step 510). The MN-CSE 34 then updates the service profile as needed (step 512). Finally, the MN-CSE 34 responds to the AE 16 with the allocated temporary identifier C2 and any other necessary information (step 514). Notably, in this embodiment, the group membership of the AE 16 has already been updated before the AE 16 receives the new temporary identifier. However, this process can be done in other orders or in parallel.

[0081 ] Figure 8 is a block diagram of a node 38 in an M2M network 10 according to some other embodiments of the present disclosure. As used herein, node 38 may be a Group Management Server 32, a MN-CSE 34, an IN-CSE 36, or any other suitable node in the M2M network 10. The node 38 includes a communication interface 40 for communication with other nodes in the M2M network 10. The node 38 also includes circuitry 42 that includes one or more processors 44 which may be one or more Central Processing Units (CPUs) for performing any of the processes described herein. Circuitry 42 also includes a memory 46 (e.g. non-volatile and volatile memory, such as hard drive, flash memory, memory stick and the like). Also, volatile memory may include random access memory and others known in the art. Memory 46 may store program instructions such as those to perform the functionality described herein.

[0082] In some embodiments, a carrier containing the aforementioned program instructions is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium.

[0083] Figure 9 is a block diagram of a node 38 in an M2M network 10 (e.g., a Group Management Server 32) with modules according to some embodiments of the present disclosure. The receiving module 48 and the determination module 50 are each implemented in software that, when executed by a processor of node 38, causes the node 38 to operate according to one of the embodiments described herein. The receiving module 48 is operative to receive an indication that a first temporary identifier associated with an AE 16 is a member of a first group. The determination module 50 is operative to determine a second node in the M2M network 10 associated with the AE 16 for validating the first temporary identifier associated with the AE 16 and validate the first temporary identifier associated with the AE 16 by querying the second node.

[0084] Figure 10 is a block diagram of a node 38 in an M2M network (e.g., an MN-CSE 34) with modules according to some embodiments of the present disclosure. The identifier allocation module 52, the receiving module 54, the binding module 56, and the update module 58 are each implemented in software that, when executed by a processor of node 38, causes the node 38 to operate according to one of the embodiments described herein. The identifier allocation module 52 is operative to allocate a first temporary identifier for an AE 16. The receiving module 54 is operative to receive a validation request message comprising the first temporary identifier for the AE 16 and one or more groups affiliated with the AE 16. The binding module 56 is operative to, in response to receiving the validation request message, maintain a binding between the first temporary identifier for the AE 16, the AE 16, and the one or more groups affiliated with the AE 16. The update module 58 is operative to, in response to receiving an indication that the AE 16 is deregistered, update a service subscription profile for the AE 16 at a second node to include the binding.

[0085] Figure 1 1 is a block diagram of a node 38 in an M2M network (e.g., an IN-CSE 36) with modules according to some embodiments of the present disclosure. The receiving module 60 and the storage module 62 are each implemented in software that, when executed by a processor of node 38, causes the node 38 to operate according to one of the embodiments described herein. The receiving module 60 is operative to receive an update for a service subscription profile for an AE 16 including a binding. The binding includes a first temporary identifier associated with the AE 16 and one or more groups affiliated with the AE 16. The storage module 62 is operative to store the binding.

[0086] Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

[0087] The following acronyms are used throughout this disclosure.

• ADN Application Dedicated Node

• AE Application Entity

• ASN Application Service Node

• CPU Central Processing Unit

• CSE Common Service Entity

• ETSI European Telecommunications Standards Institute

• IN Infrastructure Node

• IN-CSE Infrastructure Node Common Service Entity

• loT Internet of Things

• M2M Machine-to-Machine

• MN Middle Node

• MN-CSE Middle Node Common Service Entity

• NoDN Non-oneM2M Device Node

• NSE Network Service Entity

• TS Technical Specification