WO2016042512A1

WO2016042512A1 - Methods and apparatus in an m2m service provider network

Info

Publication number: WO2016042512A1
Application number: PCT/IB2015/057159
Authority: WO
Inventors: George Foti
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-09-19
Filing date: 2015-09-17
Publication date: 2016-03-24

Abstract

A plurality of machine-to-machine, M2M, service provider, SP, networks are interconnected by common protocols for communication. An underlying network (110) provides data transport services for an M2M SP network. In a M2M SP network (170), an infrastructure node (130) receives a request for instance-specific information. The instance-specific information is associated with a particular instance of an application (160) on a particular M2M device (150). The request includes access information for reaching that particular instance from the perspective of the underlying network and further includes application identifying information that identifies the application (160). Based on the access information, the infrastructure node 130 retrieves from the underlying network (110) a common identifier that identifies the particular M2M device to both the M2M SP network (170) and the underlying network (110). The infrastructure node (130) identifies the requested instance-specific information based on the common identifier and the application identifying information.

Description

METHODS AND APPARATUS IN AN M2M SERVICE PROVIDER NETWORK

RELATED APPLICATIONS

This application claims priority to U.S. Provisional patent Application Serial Number 62/052832 filed 19 September 2014, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to a machine-to-machine (M2M) service provider (SP) network, and particularly to one of a plurality of M2M SP networks that are

communicatively interconnected by common protocols (e.g., in the form of a common services layer).

BACKGROUND

Machine-to-machine (M2M) devices include devices whose end-to-end communication is not necessarily triggered by a user, at least not explicitly. An M2M device may for instance reply to a request for data contained within the device itself, or may transmit data contained within the device autonomously. M2M communication is typically initiated for instance by an application residing on an M2M device to gather or send information to a counterpart application on another M2M node, such as the infrastructure of an M2M service provider's network. As one example, an application on an M2M device (such as a sensor) may collect information (such as temperature) and transmit that information through a network (wireless, wired or hybrid) to a counterpart application another M2M node (e.g., an M2M server) that translates the collected information into meaningful information (for example, the temperature is too high). M2M is thereby a paradigm in which end-to-end communication is executed without human intervention so as to, for instance, connect non-IT objects to an IT infrastructure. M2M devices are also known as M2M nodes or machine type communication (MTC) devices.

Common protocols (e.g., in the form of a common M2M service layer) are being developed to interconnect M2M devices (e.g., across M2M service provider networks in an access-independent manner). These common protocols act as a horizontal convergence layer that support multiple vertical application domains, such as transport and logistics, utilities, automotive, etc. which may be deployed independently. One example implementation of such common protocols is being developed by oneM2M. OneM2M in this regard is developing a common M2M service layer that is readily embedded within various hardware and software, and relied upon to connect the myriad of M2M devices in the field with M2M application servers worldwide. OneM2M in this regard provides common data formats, interfaces and message sequences to support reference points defined by oneM2M. See, e.g. , OneM2M Service Layer Protocol Core candidate Specification (August 1 , 2014), which is incorporated by reference herein. An underlying network provides data support services between nodes of the oneM2M architecture. Interconnecting M2M devices via common protocols in this way introduces complexities to the way that information is associated with a particular instance of an M2M application executing on a particular M2M device, especially in the context of M2M application registration. Consider for instance the way that information in the form of a service profile is associated with a particular instance of an M2M application executing on a particular M2M device (also referred to as an "application entity") according to the current oneM2M architecture. The current oneM2M architecture allocates a service profile to every application. This service profile is downloaded at application registration. The service profile includes what operations an application is authorized to perform. Hence, the profile has to be checked against every operation initiated from the application to ensure that the application is authorized for the operation.

Each different service profile is given a distinct service profile identifier, e.g. Service Profile ID. The service profile identifier is allocated to an application and the M2M node on which the application resides at subscription time depending on subscribed services. At registration the registrar common services entity (CSE), with whom an application registers to receive M2M service, downloads the service profile using the service profile identifier.

In order for the registrar CSE to know the service profile identifier to download from the infrastructure CSE (IN-CSE), one current solution requires that the application include security credentials at registration time. These credentials can be used by the IN-CSE to identify the correct application and the corresponding applicable service profile identifier. However, in current standards for the oneM2M architecture, it is optional for the application to provide security credentials. Another option is to pre-provision the service profile identifier and then let the application include it at registration time.

Neither of these solutions prove workable in all environments, such as in a consumer environment where application designers design an application to run on multiple platforms and regardless of any security consideration. Indeed, in such an environment, the service profile associated with an application being registered cannot be identified when the optional security credentials are not provided at registration. SUMMARY

One or more embodiments herein exploit so-called access information, rather than for instance optional security credentials, to identify certain instance-specific information (e.g., a service profile) that is associated with a particular instance of an M2M application on a particular M2M device. Access information in this regard refers to information (e.g., Point of Access in the oneM2M architecture) for reaching that particular instance from the perspective of an underlying network providing data transport services for an M2M service provider network providing M2M services to the M2M device. Exploiting access information in this way advantageously allows the instance-specific information to be identified even when optional criteria such as security credentials are not available. Moreover, such access information is available at an early stage, meaning that the access information proves useful for identifying the instance-specific information even as early as M2M application registration.

Some embodiments, for instance, comprise a system in a M2M SP network for identifying instance-specific information that is associated with a particular instance of an application on a particular M2M device. The system is characterized by a registrar node and an infrastructure node. The registrar node is configured to receive a registration request for the particular instance of the application on the particular M2M device. The registration request comprises application identifying information that identifies the application and the registration request further comprises access information for reaching that particular instance from the perspective of an underlying network. The underlying network provides data transport services for the M2M SP network. The infrastructure node is configured to, based on the access information, retrieve from the underlying network a common identifier that identifies the M2M device to both the M2M SP network and the underlying network and configured to identify the instance-specific information based on the common identifier and the application identifying information.

Embodiments herein also include a method, implemented by an infrastructure node in one of a plurality of M2M SP networks that are interconnected by common protocols for communication. The method is characterized by, at the infrastructure node, receiving a request for instance-specific information that is associated with a particular instance of an application on a particular M2M device. The request includes access information for reaching that particular instance from the perspective of an underlying network that provides data transport services for the M2M SP network and further includes application identifying information that identifies the application. The method also comprises based on the access information, retrieving from the underlying network a common identifier that identifies the particular M2M device to both the M2M SP network and the underlying network. The method also comprises identifying the requested instance-specific information based on the common identifier and the application identifying information.

In one or more embodiments, identifying the requested instance-specific information comprises mapping the common identifier to a SP-specific device identifier that exclusively and uniquely identifies the particular M2M device to the M2M SP network but does not commonly identify the M2M device to the underlying network, and identifying the requested instance- specific information from the SP-specific device identifier and the application identifying information.

In one or more embodiments, receiving the request for the instance-specific information comprises receiving the request from a registrar node in the M2M SP network, and identifying the requested instance-specific information comprises identifying the requested instance- specific information also based on an identity of the registrar node. In one or more embodiments, a method implemented by the infrastructure node in accordance herein is further characterized by storing the common identifier in a cache as mapped to the access information. In embodiments herein the infrastructure node receives a subsequent request for instance-specific information, the subsequent request including the same access information as said request. The infrastructure node retrieves from the cache the common identifier mapped to the access information in the subsequent request and identifies the instance-specific information requested by the subsequent request based on the common identifier retrieved from the cache.

In one or more embodiments, the infrastructure node responds to the request with the identified instance-specific information.

Embodiments herein also include a method, implemented by an inter-working node in an underlying network. The underlying network is configured to provide data transport services for a machine-to-machine (M2M) service provider (SP) network. The method is characterized by, at the inter-working node, receiving a request from an infrastructure node in the M2M SP network for a common identifier that identifies a particular M2M device to both the M2M SP network and the underlying network. The request includes access information for reaching a particular instance of an application on the particular M2M device from the perspective of the underlying network. The method also comprises retrieving the common identifier, based on a mapping by the underlying network between the common identifier and the access information and sending the common identifier to the infrastructure node as a response to the request.

In one or more embodiments, the mapping by the underlying network comprises mapping the access information to an underlying-network-specific device identifier that exclusively and uniquely identifies the particular M2M device to the underlying network, and then mapping the underlying-network-specific device identifier to the common identifier.

In one or more embodiments, the underlying network is an access network of a cellular network and the underlying-network specific device identifier is an International Mobile

Subscriber Identity (IMSI).

In one or more embodiments, the common identifier is dynamically allocated in the response to the request for the common identifier.

In one or more embodiments, the common identifier is retrieved from a Home Subscriber

Server of the underlying network.

In one or more embodiments, the infrastructure node is a node implementing an infrastructure common services entity (CSE) in a oneM2M architecture and the underlying network is an access network for a subscribed M2M device.

Embodiments herein also include a method implemented by a registrar node in one of a plurality M2M SP networks that are interconnected by common protocols for communication. The method is characterized by, at the registrar node, receiving a request to register a particular instance of an application on a particular M2M device with the registrar node. The registration request includes access information for reaching that particular instance from the perspective of an underlying network that provides data transport services for the M2M SP network and further includes application identifying information that identifies the application. The method also comprises retrieving instance-specific information that is associated with the particular instance of the application on the particular M2M device, by sending a request for the instance-specific information to an infrastructure node, the request including said access information and said application identifying information.

In one or more embodiments, the registrar node associates the particular instance of the application with the retrieved instance-specific information. Associating the particular instance of the application with the retrieved instance-specific information comprises binding the application identifying information with the retrieved instance-specific information and one or more of: an identity of the registrar node and a SP-specific device identifier. The SP-specific device identifier identifies the particular M2M device to the M2M SP network.

In one or more embodiments, retrieving instance-specific information comprises retrieving the instance-specific information based on a mapping of a common identifier to the identity of the registrar node and a mapping of the identity of the registrar node and the application identifying information to a SP-specific device identifier. The SP-specific device identifier exclusively and uniquely identifies the particular M2M device to the M2M SP network.

In one or more embodiments, the registrar node receives a common identifier that identifies the particular M2M device to both the M2M SP network and the underlying network in response to the request for instance-specific information. In such embodiments, retrieving instance-specific information comprises retrieving instance-specific information based on the common identifier.

In one or more embodiments, the request for instance-specific information does not include security credentials and/or an identifier of the instance-specific information.

In one or more embodiments, the common identifier is an M2M External Identifier (M2M- Ext-ID) in a oneM2M architecture.

In one or more embodiments, the SP-specific device identifier is an M2M-Node-ID and/or a CSE-ID in a oneM2M architecture.

In one or more method embodiments, the method is performed as part of the particular instance of the application registering with a registrar node in the M2M Service Provider Network to receive M2M services.

In one or more embodiments, the M2M device is an Application Dedicated Node (ADN) in a oneM2M architecture and the access information is a point of access in the oneM2M architecture.

In one or more embodiments, the M2M device is an Application Service Node (ASN) in a oneM2M architecture and the access information is a point of access in the oneM2M architecture. In one or more embodiments, the access information is an IP address of a node in the M2M SP network for reaching the particular instance of the application.

In one or more embodiments, the instance-specific information is a service profile that defines operations that the particular instance of an application on the particular M2M device is authorized by the M2M SP network to perform.

Embodiments herein also include corresponding apparatus, computer programs, and carriers containing such computer programs.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of an M2M system according to one or more embodiments.

Figure 2 is a logic flow diagram of a method implemented by an infrastructure node of an M2M Service Provider Network according to one or more embodiments.

Figure 3 is a logic flow diagram of a method implemented by an inter-working node of an underlying network according to one or more embodiments.

Figure 4 is a logic flow diagram of a method implemented by a registrar node of an M2M

Service Provider Network according to one or more embodiments.

Figure 5 illustrates a system-view of the above methods according to one or more embodiments, in the context of an M2M application registration.

Figure 6 illustrates a flow diagram of the above methods according to one or more embodiments, in the context of an M2M application registration.

Figure 7 is a block diagram of a node according to one or more embodiments.

Figure 8 is a block diagram of an M2M system according to one or more embodiments. Figure 9 is a M2M common services entity resource according to one or more embodiments.

Figure 10 is a M2M application entity resource according to one or more embodiments.

Figure 1 1 is a service profile resource according to one or more embodiments.

DETAILED DESCRIPTION

Figure 1 illustrates an M2M system according to one or more embodiments. The M2M system includes an M2M service provider (SP) network 170 that is for instance one of a plurality of M2M SP networks communicatively interconnected by common protocols (e.g., in the form of a common service layer, such as that specified in the oneM2M architecture). An underlying network 1 10 (e.g., an access network) provides support services (e.g. data transport services) for the M2M SP network 170.

The M2M SP network 170 includes an M2M device 150 (e.g., an Application Dedicated

Node, ADN, or Application Service Node, ASN, in the oneM2M architecture) that executes a particular instance of an M2M application 160 (also referred to as an "application entity").

Certain instance-specific information (e.g., a service profile) is associated with this particular instance of the application 160. The instance-specific information may be for example associated with the particular instance upon subscribing to the M2M services provided by the M2M SP network 170. Regardless, an infrastructure node 130 in the M2M SP network 170 (e.g., a node implementing an infrastructure common services entity, IN-CSE, in the oneM2M architecture) advantageously exploits so-called access information to identify this instance- specific information, e.g., during registration of the M2M application 160. Access information in this regard refers to information (e.g., Point of Access in the oneM2M architecture) for reaching that particular instance from the perspective of the underlying network 1 10.

Exploiting access information in this way advantageously allows the infrastructure node 130 to identify the instance-specific information even when optional criteria such as security credentials is not available. Moreover, such access information is available at an early stage, meaning that the access information proves useful for identifying the instance-specific information even as early as M2M application registration.

Embodiments herein are applicable for identifying any sort of instance-specific information that is associated with a particular instance of an M2M application on a particular M2M device. One example of such instance-specific information, though, is a service profile. A service profile (e.g., among other things) defines operations that the M2M SP network 170 authorizes the particular instance of the M2M application 160 on the particular M2M device 150 to perform. Moreover, embodiments herein are applicable for identifying instance-specific information at any given time. One example of a point in time at which the infrastructure node 130 identifies instance-specific information is upon registration of the M2M application 160 with a registrar node 140 in the M2M SP network 170 (which may be the same node or a different node than the M2M device 150 or infrastructure node 130, and may be a node implementing a CSE in the oneM2M architecture). With an understanding that a service profile is just one example of instance-specific information, and that application registration is just one example of when the infrastructure node 130 identifies that information, various embodiments below will be described in the context of these specific examples.

Figure 2 in this regard illustrates a method implemented by the infrastructure node 130 according to one or more embodiments. The method includes receiving a request for instance- specific information (Block 210). The instance-specific information is associated with a particular instance of an M2M application 160 on a particular M2M device 150. For example, the instance-specific information in some embodiments is a service profile that defines operations that the M2M SP network 170 authorizes the particular instance of the application 160 on the particular M2M device 150 to perform. The request includes access information for reaching that particular instance from the perspective of the underlying network 1 10. In some embodiments, the access information is for directly reaching the particular instance (e.g., the information is in the form of an application entity Point of Access, AE-PoA, in the oneM2M architecture). In other embodiments, though, the access information is for indirectly reaching the particular instance, e.g., via the registrar node 140 (e.g., the information is in the form of a CSE-PoA in the oneM2M architecture). In any event, the request further includes application identifying information that identifies the application 160, at least in generic terms such that the information does not uniquely identify the particular instance of that application executed on the particular M2M device 150 (e.g., the Application Identifier, App-ID, in the oneM2M architecture).

The method further includes, based on the access information, retrieving (e.g., from the underlying network 1 10) a common identifier that identifies the particular M2M device 150 to both the M2M SP network 170 and the underlying network 1 10 (Block 230). This common identifier may be for instance the M2M External Identifier, M2M-Ext-ID, in the oneM2M architecture. Irrespective of the particular form of this common identifier, the method further entails identifying the requested instance-specific information based on the common identifier and the application identifying information (e.g., based on information, such as an identifier of the instance-specific information, derived from the common identifier and the application identifying information) (Block 250).

In at least some embodiments, identifying the instance-specific information in this regard involves mapping the common identifier to a SP-specific device identifier that exclusively and uniquely identifies the particular M2M device 150 to the M2M SP network 170; that is the SP- specific device identifier does not commonly identify the device 150 also to the underlying network 1 10. Such an identifier may be for instance an M2M Node Identifier (M2M-Node-ID) in the oneM2M architecture. Regardless, identification in these embodiments more specifically entails identifying the requested instance-specific information from the SP-specific device identifier and the application identifying information. In one embodiment, for instance, identification involves mapping the combination of the SP-specific device identifier and the application identifying information to an identifier of the requested instance-specific information (e.g., where the instance-specific information is a service profile, the M2M Service Profile Identifier, M2M-Service-Profile-ID, in the oneM2M architecture), and retrieving the requested instance-specific information using that identifier.

Note that, in one or more embodiments, the infrastructure node 130 cannot itself identify the requested instance-specific information based on the access information (at least initially), since the access information does not inherently identify the particular M2M device 150 to the infrastructure node 130. Indeed, the access information refers to information for reaching the particular instance of the application on the device 150 from the perspective of the underlying network 1 10. The infrastructure node 150, though, may advantageously exploit the underlying network 1 10 as being able to map the access information to a common identifier that the infrastructure node 130 understands as uniquely identifying the M2M device 150. The infrastructure node 130 then identifies the requested instance-specific information based on that common identifier. In some embodiments, the infrastructure node 130 initially requests the common identifier from the underlying network 1 10 based on the access information. The infrastructure node 130 thereafter caches or otherwise stores the common identifier (as mapped to the access information), for subsequent use in identifying the instance-specific information (e.g., service profile). This means that the infrastructure node 130 may identify any instance-specific information by either retrieving the common identifier from the underlying network 1 10 or by retrieving the common identifier from its cache or other storage. For example, retrieving the common identifier from its cache in response to a registration request includes the same access information as a previous request.

Figure 3 correspondingly illustrates a method implemented by an interworking node 120 in the underlying network 1 10 for retrieving the common identifier for the infrastructure node 130. The method in particular includes receiving a request from the infrastructure node 130 for the common identifier (Block 310). This request includes the access information for reaching the particular instance of the application 160 on the particular M2M device 150. The method further entails retrieving the common identifier, based on a mapping maintained by the underlying network 1 10 between the common identifier and the access information (Block 330). This mapping may be direct or indirect. In one embodiment, for instance, the method involves mapping the access information to an underlying-network-specific device identifier that exclusively and uniquely identifies the device 150 to the underlying network 1 10, and then mapping the underlying-network-specific device identifier to the common identifier. In one embodiment, for example, the underlying-network-specific device identifier is an International Mobile Subscriber Identity (IMSI) and the access information is an IP address allocated to the device 150. Such an embodiment is applicable when the underlying network is an access network of a cellular network. Regardless of the particular mapping implementation, though, the method further includes sending the common identifier to the infrastructure node 130 as a response to the request (Block 350).

Note that in some embodiments the interworking node is configured to dynamically allocate the common identifier (optionally in cooperation with the infrastructure node 130) in response to the request for that identifier. That is, the interworking node allocates the common identifier so as to create a mapping between the allocated common identifier and the access information, and then returns the allocated common identifier as a response to the request for that identifier.

In at least some embodiments, the identification of the instance-specific information is performed as part of the M2M device 150 registering the application 160 with the registrar node 140 (e.g., a node implementing a CSE in the oneM2M architecture). Where the M2M device 150 performs registration with only one registrar node 140, the identity of that registrar node 140 may effectively identify the M2M device 150 as a sort of proxy identifier based on the one-to-one association between the M2M device 150 and registrar node 140. In such a case, identifying the instance-specific information may involve mapping the common identifier to a registrar identifier that uniquely identifies the registrar node 140 with which the M2M device 140 registers. Such an identifier may be for instance a CSE-ID in the oneM2M architecture. Regardless, identification in these embodiments more specifically entails identifying the requested instance-specific information from the registrar identifier and the application identifying information. In one embodiment, for instance, identification involves mapping the combination of the registrar identifier and the application identifying information to an identifier of the requested instance- specific information (e.g., where the instance-specific information is a service profile, the M2M Service Profile Identifier, M2M-Service-Profile-ID, in the oneM2M architecture), and retrieving the requested instance-specific information using that profile identifier.

Irrespective of the particular way identification pf the instance-specific information is performed by the infrastructure node 130, Figure 4 illustrates a method performed by the registrar node 140 in embodiments where identification of the instance-specific information is performed as part of application registration. As shown, the method includes receiving a request to register the particular instance of the M2M application 160 on the particular M2M device 150 with the registrar node 140 (Block 410). The request notably includes the access information and application identifying information described above. The method then includes retrieving (as part of the registration) instance-specific information that is associated with the particular instance of the application 160 on the particular M2M device 150. (Block 430). The instance- specific information is, for instance, a service profile that defines operations that the M2M SP network 170 authorizes the particular instance to perform. Such retrieval in particular involves sending a request for the instance-specific information to the infrastructure node 130, with that request including the access information and the application identifying information.

In one or more embodiments, the method at the registrar node 140 further includes associating the particular instance of the application 160 with the retrieved instance-specific information (Block 470). The method in this regard may further include receiving an SP-specific device identifier that identifies the particular M2M device 150 to the M2M SP network 170 (Block 450). Such identifier may be received from the infrastructure node 130 together with instance- specific information as a response to the request. Having received the SP-specific device identifier, the registrar node 140 associates the particular instance with the instance-specific information by establishing a binding between the application identifying information, the SP- specific device identifier, and an identifier of the instance-specific information, e.g., for the duration of the registration. Alternatively, as alluded to above, the registrar node 140 may associate the particular instance of the application 160 with the instance-specific information using the registrar identifier (e.g., CSE-ID) rather than or in addition to the SP-specific device identifier. Figure 5 illustrates a system-view of the above methods according to one or more embodiments, in the context of retrieving instance-specific information in the form of a service profile at application registration.

In this context, the particular instance of the application 160 on the M2M device 150 registers with an underlying network 1 10 (e.g., an access network). Upon registration with the underlying network 1 10, the M2M device 150 acquires access information (e.g. an IP address) that indicates how the particular instance of the application 160 can be reached from the perspective of the underlying network 1 10.

As shown in Figure 5, the M2M device 150 provides this access information to a registrar node 140 in the M2M service provider network 170 when registering the application 160 with that registrar node 140. The M2M device 150 does so by including the access information, along with an application identifier (App-ID) that identifies the application 160, within a registration request sent to the registrar node 140 (Step 1). The application identifier is not guaranteed to be globally unique on its own. In other words, the application identifier may only be understood in a particular context (e.g., within a particular M2M SP network).

The registrar node 140 uses this access information to retrieve a service profile for the particular instance of the application 160 on the M2M device 150. The registrar node 140 in this regard sends a service profile request to an infrastructure node 130 in the M2M service provider network 170 (e.g., an IN-CSE in a OneM2M architecture) (Step 2). The registrar node 140 includes the access information and the application identifier in that service profile request.

Although Figure 5 shows that the infrastructure node 130 receives the service profile request directly from a registrar node 140, the infrastructure node 130 in other embodiments receives the request for the service profile directly from the M2M device 150. In these other embodiments, for instance, the M2M device comprises a common services entity (e.g., an Application Service Node, ASN, of the OneM2M architecture).

Regardless, in step 3 of Figure 5, the infrastructure node 130 uses information in the request for a service profile to request a common identifier for the M2M device 150 from the underlying network 1 10. The infrastructure node 130 more particularly includes the access information in the common identifier request and sends the request to an inter-working node 120 of the underlying network 1 10 (e.g., an Interworking Function (IWF) of an access network). The inter-working node 120 uses the access information provided in the request to locate the common identifier for the M2M device (e.g., an M2M-External-ldentifier in a OneM2M architecture) (Step 4).

In step 5, the inter-working node 120 returns the common identifier to the infrastructure node 130. The infrastructure node 130 in step 6 uses the common identifier and application identifier to retrieve the service profile for the specific instance of the application 160 on the M2M device 150. In step 7, the service profile is sent to the registrar node 140. In step 8, the registrar node 140 associates the service profile with the application 160 of the M2M device. In step 9, the M2M device determines that registration has been successful. In particular, the M2M device 150 now has a service profile for the particular instance of the application 160.

Embodiments herein are not limited to any particular architecture for communicatively interconnecting different M2M SP networks. Nonetheless, embodiments will now be described in the context of the oneM2M architecture. See, e.g., oneM2M Service Layer Protocol Core candidate Specification (August 1 , 2014), for more details on the One M2M architecture, which is incorporated by reference herein. The oneM2M architecture uses a layered model with entities, resources and/or objects residing in an application layer, common services layer, or a network services layer. An underlying network provides data transport services between entities in the OneM2M system.

An application entity (AE) in oneM2M resides at the application layer. Examples of the application entities can be an instance of a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application.

A common services entity (CSE) in oneM2M resides in the common services layer and represents an instantiation of a set of common services of the M2M environments. Such services are exposed to other entities through reference points Mca and Mcc. Examples of service functions offered by CSE include: Data Management, Device Management, M2M Subscription Management, and Location Services.

A network services entity (NSE) in oneM2M resides in the network services layer. A NSE provides services from the underlying network to the CSEs. Examples of such services include device management, location services and device triggering.

OneM2M uses various M2M identifiers for identifying an entity, a resource, or an object within this layered architecture. For example, an M2M-External-ldentifier identifies an M2M device. Embodiments herein exploit these M2M identifiers to identify instance-specific information.

In general, an M2M identifier can be either absolute or relative. If it is absolute it is globally unique and is a unified resource identifier (URI). If it is relative, it is understood in a particular context (e.g., within a particular M2M SP network). An M2M identifier can be either hierarchical (i.e. it adheres to a predefined structure for URIs) or non-hierarchical (i.e. it does not adhere to a predefined structure for URIs).

A hierarchical URI has its path portion defining the entire relationship for the target resource within the resource structure. Example A is shown below. This is a structured representation of the resources within a CSE where the parent relationship chain is embedded in the resource address.

EXAMPLE A: "<scheme>://IN-CSEID. m2m.myoperator.org/CSE123/myAppX/myContainerY".

A non-hierarchical URI does not have its path portion reflecting the entire relationship for the target resource within the resource structure. The actual parent relationship chain is not known a priori from reading the path portion of the URI, and the hosting CSE needs to resolve the logical location of the target resource in the chain of relationships within the resource structure following links. That path portion of the URL can be of any depth. Example B is such an example.

EXAMPLE B: "<scheme>://IN-CSEID. m2m.myoperator.org/CSEBase/mCY" where the same container of Example A.

Some oneM2M embodiments use an M2M-External-ldentifer (M2M-Ext-ID) as a common identifier. The M2M-Ext-ID is allocated by an underlying network such as an access network to a subscribed M2M device. The M2M-Ext-ID identifies a particular M2M node to both the M2M SP network and the access network. It is a common identifier that both the M2M service provider network and the access network understand as uniquely identifying a particular M2M node.

The M2M-Ext-ID is used by an M2M Service Provider when services targeted to a CSE, identified by a CSE-ID, are requested from the Underlying Network. The M2M External Identifier allows the Underlying Network to identify the M2M Device (e.g., ASN) associated with the CSE-ID. To that effect, the Underlying Network maps the M2M-Ext-ID to the Underlying Network specific Identifier it allocated to the target M2M Device. In addition, the M2M Service Provider maintains the association between the CSE-ID, the M2M-Ext-ID and the identity of the Underlying Network.

For each CSE-ID, there is only one M2M-Ext-ID for a specific underlying network. Hence an M2M SP interworking with multiple Underlying Networks has different M2M-Ext-IDs associated with the same CSE-ID, one per Underlying Network, and selects the appropriate M2M-Ext-ID for any service request it initiates towards an Underlying Network. The Underlying Network provider and the M2M Service Provider collaborate for the assignment of an M2M-Ext- ID to each CSE identified by CSE-ID. At the same time, the Underlying Network provider maintains association of the M2M-Ext-ID with the Underlying Network specific Identifier allocated to the M2M device that hosts such CSE.

One M2M supports pre-provisioned and dynamic association between the CSE-ID and the M2M-Ext-ID. For pre-provisioned M2M-Ext-IDs, the M2M-Ext-ID along with the associated CSE-ID shall be made available at the Infrastructure Node. The CSE at M2M device does not need to have knowledge of the M2M-Ext-ID assigned to it. For dynamic M2M-Ext-IDs, the

M2M-Ext-ID specific to the Underlying Network shall be made available at the M2M device and is conveyed to the IN-CSE during CSE Registration.

Figure 6 shows an example flow diagram for one or more embodiments implemented in the oneM2M architecture. In One M2M architecture an M2M device be for example an Application Service Node (ASN) or an Application Dedicated Node (ADN). Each node supports an application entity according to one or more embodiments. In step 1 of Figure 6, the application entity Application 600 registers with a CSE 610 in a field domain. The registration request includes access information in an attribute called Point of Access (POA). The access information may be an IP address for reaching the application. The registration request also includes application identifying information in an attribute called App-ID.

In step 2 of Figure 6, the CSE 610 sends a query request to a CSE entity in the infrastructure domain (IN-CSE 620) to retrieve a service profile for the application 600. The request includes the App ID and the point of access (PoA) for reaching the registered application. The point of access may be for example in the form of an application entity Point of Access (AE-PoA). In other embodiments, though, the access information is for indirectly reaching the particular instance (e.g., the information is in the form of a CSE-PoA).

In step 3 of Figure 6, the IN-CSE 620 sends a query request to an interworking node of the access network (e.g. an inter-working function IWF 630) to locate a common identifier corresponding to the PoA. In one embodiment shown in Figure 6, the IN-CSE sends a request for a M2M-External-ID. In step 4, the IWF 630 sends the query request to a Home Subscriber Server (HSS) 640 in the access network to locate the M2M-External-ID. In step 5, the access network returns the corresponding M2M-External-ID to the IWF 630.

In step 6 of Figure 6, the IWF 630 returns the response to the IN-CSE 620. In step 7, the IN-CSE 620 uses the returned M2M-External-ID to locate a corresponding M2M-Node-ID and/or the CSE-ID from information stored at the IN-CSE 620 (i.e., its provisioned information) (although Figure 6 just shows the M2M-Node-ID scenario). The CSE-ID is a globally unique identifier that identifies a CSE 610. It is sufficient to be unique within that M2M Service Provider domain. It is extended to become globally unique when used outside the M2M Service Provider boundaries. The M2M-Node-ID identifies an M2M node hosting a CSE and/or application and is identified by a globally unique identifier. The M2M-Node-ID enables the M2M Service Provider to bind a CSE-ID to a specific M2M Node. In some M2M systems, the M2M Service Provider sets the CSE-ID and the M2M-Node-ID to the same value. The M2M Service Provider may allocate a globally unique M2M-Node-ID using Object Identity (OID) and International Mobile Station Equipment Identity (IMEI).

Using this information in conjunction with the App-ID enables the IN-CSE 620 to locate a service profile identifier (service profile ID) corresponding to the application 600 on the specific M2M device. In step 8, the IN-CSE 620 returns the identified service profile information as well as the Service Profile ID. The profile information, for instance, is the particular operations an application with the associated service profile can perform. In step 9, the CSE 610 maintains a binding or association between registered App-ld and the Service Profile ID for the duration of the registration. In step 10, the CSE 610 returns a success response to the registered application 600.

In other embodiments not shown in the flow diagram, the IN-CSE communicates with several access networks and cannot tell to which access the PoA belong. In this case, it can send the request to all IWF and those for which the PoA does not belong will return a negative result. Embodiments herein further include corresponding apparatus configured to perform the methods described above. An apparatus may include any means, modules, or functional units for performing the corresponding method above.

Figure 7 illustrates a block diagram of exemplary components of an example node herein. The node may be an interworking node (e.g., a node implementing the IWF), a registrar node, an infrastructure node, or an M2M device. As shown in Figure 7, the node includes one or more processing circuits 710, a memory 730, and one or more communication interfaces 750. The one or more processing circuits 710 control the operation of the node to perform functionality described above, e.g., via the communication interface(s).

The circuits described above may comprise one or more processors, hardware circuits, firmware, or a combination thereof. The node in this regard may comprise memory that includes one or more volatile and/or non-volatile memory devices. Program code for controlling operation of the node may be stored in a non-volatile memory, such as a read-only memory or flash memory. Temporary data generated during operation may be stored in random access memory. Program code stored in memory, when executed by the processing circuit(s), causes the processing circuit(s) to perform the methods shown above.

In certain embodiments, an M2M device is an application dedicated node (ADN) and in others the M2M device is an application services node (ASN). A M2M service provider network may include one or more ADNs or one or more ASNs. Figure 8, in this regard, illustrates an example embodiment where an M2M service provider network includes two M2M devices: an ADN 840 with an application entity (AE) 800 and an ASN 850 with a common services entity 820 and an AE 810. Each M2M device communicates with an infrastructure node 130.

In oneM2M communication flows between an application entity and a common services entity across an Mca reference point (e.g., Mca 760A and 760B). Communication flows between two CSEs across an Mcc reference point (e.g., Mcc 770). Thus, in one or more embodiments the AE 800 of the ADN 840 communicates with an IN-CSE 830 of an infrastructure node 130 in the M2M Service Provider Network 170 across an Mca reference point 760A. The CSE 820 of the ASN 850 communicates with an IN-CSE 830 of an infrastructure node 130 in the M2M Service Provider Network 170 across an Mcc reference point 770.

Various entities as described herein may be represented as a resource in a oneM2M architecture. Figure 9 in this regard illustrates an example representations of a Common Services Entity in a oneM2M architecture. Such a Common Services Entity may be represented by the <CSEBase> resource 900. The <CSEBase> resource 900 is the root for all resources that are residing in the CSE. The resource may have attributes as described herein. For example the <CSE Base> resource 900 includes a CSE-ID 910 and CSE pointOfAccess (PoA) 920.

The <CSE Base> resource 900 may be for example a registrar CSE. In such a case, a <remoteCSE> resource 930 shall represent a remote CSE that is registered to the Registrar CSE. <remoteCSE> resources 930 shall be located directly under the <CSEBase> resource 900. Each registered CSE shall also be represented as a <remoteCSE> resource in the registering CSE's <CSEBase>. For example, when CSE1 registers with CSE2, there will be two <remoteCSE> resources created: one in CSE1 : <CSEBase1 >/<remoteCSE2> and one in CSE2: <CSEBase2>/<remoteCSE1 >. Note that the creation of the two resources does not imply mutual registration. The <CSEBase1 >/<remoteCSE2> does not mean CSE2 registered with CSE1 in the example above. The <remoteCSE> resource 930 may comprise information such as a CSE PoA 940 and CSE-ID 950 as explained herein.

The <CSE Base> resource 900 may also include application entity information, <AE> resource 960 for an application entity registered with the <CSE Base> resource 900.

Figure 10 in this regard illustrates an example representations of an application entity, <AE> resource 960. The application entity has an App-ID 1010 attribute as explained herein. The Application identifier identifies the application and is not guaranteed to be globally unique on its own. Additionally, the application entity has a pointOfAccess (PoA) 1020 attribute as explained herein. The PoA may comprise multiple different access information. For example, it can comprise a list of addresses for communicating with the registered Application Entity over Mca reference point via the transport services provided by Underlying Network. Such routing information may comprise an IP address as explained herein. It may also comprise an FQDN or URI. The PoA attribute is accessible only by the AE and the hosting CSE. Subscription information 1030 may be associated with the application entity.

Figure 1 1 illustrates an example representation of instance-specific information in the form of a service profile in a one M2M architecture. The <m2mServiceSubscriptionProfile> 1 100 resource represents an M2M Service Subscription. It is used to represent data pertaining to the M2M Service Subscription 1 120, i.e., the technical part of the contract between an M2M Application Service Provider and an M2M Service Provider. The service Roles attribute 1 1 10 contains a list of Service Role IDs (S-RolelDs) that are subscribed to in this service subscription.

Embodiments herein thereby further include a computer program comprising

instructions, which when executed on at least one processor of a node, cause the node to carry out the method(s) above. Embodiments further include a carrier containing such a computer program, where the carrier is one of an electrical signal, an optical signal, a radio signal, or a computer readable storage medium.

Embodiments of course also include an M2M system that includes the infrastructure node and registrar node herein.

Claims

CLAIMS What is claimed is:

1 . A system in a machine-to-machine, M2M, service provider, SP, network (170) for identifying instance-specific information that is associated with a particular instance of an application (160) on a particular M2M device (150), the system characterized by:

a registrar node (140) configured to receive a registration request for the particular

instance of the application (160) on the particular M2M device (150), the registration request comprising application identifying information that identifies the application and the registration request further comprising access information for reaching that particular instance from the perspective of an underlying network (1 10), wherein the underlying network (1 10) provides data transport services for the M2M SP network (170); and

an infrastructure node (130) configured to, based on the access information, retrieve from the underlying network (1 10) a common identifier that identifies the M2M device (150) to both the M2M SP network (170) and the underlying network (1 10) and configured to identify the instance-specific information based on the common identifier and the application identifying information.

2. A method, implemented by an infrastructure node (130) in one of a plurality of machine- to-machine, M2M, service provider, SP, networks that are interconnected by common protocols for communication, the method characterized by:

at the infrastructure node (130), receiving a request for instance-specific information that is associated with a particular instance of an application (160) on a particular M2M device (150), and wherein the request includes access information for reaching that particular instance from the perspective of an underlying network (1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; based on the access information, retrieving from the underlying network (1 10) a common identifier that identifies the particular M2M device (150) to both the M2M SP network and the underlying network (1 10); and

identifying the requested instance-specific information based on the common identifier and the application identifying information.

3. The method of claim 2, wherein identifying the requested instance-specific information comprises mapping the common identifier to a SP-specific device identifier that exclusively and uniquely identifies the particular M2M device (150) to the M2M SP network (170) but does not commonly identify the M2M device (150) to the underlying network (1 10), and identifying the requested instance-specific information from the SP-specific device identifier and the application identifying information.

4. The method of any of claims 2-3, wherein receiving the request for the instance-specific information comprises receiving the request from a registrar node (140) in the M2M SP network

(170), and identifying the requested instance-specific information comprises identifying the requested instance-specific information also based on an identity of the registrar node (140).

5. The method of any of claims 2-4, further characterized by:

storing the common identifier in a cache as mapped to the access information;

receiving a subsequent request for instance-specific information, the subsequent request including the same access information as said request;

retrieving from the cache the common identifier mapped to the access information in the subsequent request; and

identifying the instance-specific information requested by the subsequent request based on the common identifier retrieved from the cache.

6. The method of any of claims 2-5, further characterized by responding to the request with the identified instance-specific information.

7. A method, implemented by an inter-working node (120) in an underlying network (1 10), the underlying network (1 10) configured to provide data transport services for a machine-to- machine, M2M, service provider, SP, network, (170) the method characterized by:

at the inter-working node (120), receiving a request from an infrastructure node (130) in the M2M SP network (170) for a common identifier that identifies a particular

M2M device (150) to both the M2M SP network (170) and the underlying network (1 10), wherein the request includes access information for reaching a particular instance of an application on the particular M2M device (150) from the perspective of the underlying network (1 10);

retrieving the common identifier, based on a mapping by the underlying network (1 10) between the common identifier and the access information; and sending the common identifier to the infrastructure node (130) as a response to the request.

8. The method of claim 7, wherein the mapping by the underlying network (1 10) comprises mapping the access information to an underlying-network-specific device identifier that exclusively and uniquely identifies the particular M2M device (150) to the underlying network (1 10), and then mapping the underlying-network-specific device identifier to the common identifier.

9. The method of claim 8, wherein the underlying network (1 10) is an access network of a cellular network and the underlying-network specific device identifier is an International Mobile

Subscriber Identity, IMSI.

10. The method of any of claims 7-9, further characterized by dynamically allocating the common identifier in response to the request for the common identifier.

1 1 . The method of any of claims 2-10, wherein the common identifier is retrieved from a Home Subscriber Server, HSS, (640) of the underlying network (1 10).

12. The method of any of claims 2-1 1 , wherein the infrastructure node (130) is a node implementing an infrastructure common services entity, CSE, in a oneM2M architecture and the underlying network (1 10) is an access network for a subscribed M2M device (150).

13. A method, implemented by a registrar node (140) in one of a plurality of machine-to- machine, M2M, service provider, SP, networks that are interconnected by common protocols for communication, the method characterized by:

at the registrar node (140), receiving a request to register a particular instance of an application on a particular M2M device (150) with the registrar node (140), wherein the registration request includes access information for reaching that particular instance from the perspective of an underlying network (1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; and retrieving instance-specific information that is associated with the particular instance of the application on the particular M2M device (150), by sending a request for the instance-specific information to an infrastructure node (130), the request including said access information and said application identifying information.

14. The method of claim 13, wherein the method is characterized by associating the particular instance of the application with the retrieved instance-specific information, and wherein associating the particular instance of the application with the retrieved instance-specific information comprises binding the application identifying information with the retrieved instance-specific information and one or more of the following:

an identity of the registrar node (140); and a SP-specific device identifier that identifies the particular M2M device (150) to the M2M SP network.

15. The method of any of claims 13-14, wherein retrieving instance-specific information comprises retrieving the instance-specific information based on a mapping of a common identifier to the identity of the registrar node (140) and a mapping of the identity of the registrar node (140) and the application identifying information to a SP-specific device identifier, the SP- specific device identifier exclusively and uniquely identifies the particular M2M device (150) to the M2M SP network (170).

16. The method of any of claims 13-15, wherein the method is characterized by receiving a common identifier that identifies the particular M2M device (150) to both the M2M SP network (170) and the underlying network (1 10) in response to the request for instance-specific information and retrieving instance-specific information comprises retrieving instance-specific information based on the common identifier.

17. The method of any of claims 2-6 or 13-16, wherein the request for instance-specific information does not include security credentials and/or an identifier of the instance-specific information.

18. The method of any of claims 2-12 or 15-16, wherein the common identifier is an M2M External Identifier, M2M-Ext-ID, in a oneM2M architecture.

19. The method of claims 3, 14, or 15, wherein the SP-specific device identifier is an M2M- Node-ID and/or a CSE-ID in a oneM2M architecture.

20. The method of any of claims 2-19, wherein the method is performed as part of the particular instance of the application registering with a registrar node (140) in the M2M SP network (170) to receive M2M services.

21 . The method of any of claims 2-20, wherein the M2M device (150) is an Application Dedicated Node, ADN, (840) in a oneM2M architecture and the access information is a point of access in the oneM2M architecture.

22. The method of any of claims 2-20, wherein the M2M device (150) is an Application Service Node, ASN, (850) in a oneM2M architecture and the access information is a point of access in the oneM2M architecture.

23. The method of any of claims 2-22, wherein the access information is an IP address of a node in the M2M SP network for reaching the particular instance of the application.

24. The method of any of claims 2-23, wherein the instance-specific information is a service profile that defines operations that the particular instance of the application on the particular

M2M device (150) is authorized by the M2M SP network (170) to perform.

25. An infrastructure node (130) in one of a plurality of machine-to-machine, M2M, service provider, SP, networks that are communicatively interconnected by common protocols, the infrastructure node (130) configured to:

receive a request for instance-specific information that is associated with a particular instance of an M2M application on a particular M2M device (150), and wherein the request includes access information for reaching that particular instance from the perspective of an underlying network (1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; based on the access information, retrieve from the underlying network (1 10) a common identifier that identifies the particular M2M device (150) to both the M2M SP network (170) and the underlying network (1 10); and

identify the requested instance-specific information based on the common identifier and the application identifying information.

26. The infrastructure node (130) of claim 25 configured to implement the method of any of claims 2-6 or 17-24.

27. An inter-working node (120) in an underlying network (1 10), the underlying network (1 10) configured to provide data transport services for a machine-to-machine, M2M, service provider, SP, network, the node configured to:

receive a request from an infrastructure node (130) in the M2M SP network for a

common identifier that identifies a particular M2M device (150) to both the M2M

SP network and the underlying network (1 10), wherein the request includes access information for reaching a particular instance of an application on particular M2M device (150) from the perspective of the underlying network (1 10);

retrieve the common identifier, based on a mapping by the underlying network (1 10) between the common identifier and the access information; and send the common identifier to the infrastructure node (130) as a response to the request.

28. The inter-working node (120) of claim 27 configured to implement the method of any of claims 7-12 or 20-24.

29. A registrar node (140) in one of a plurality of machine-to-machine, M2M, service provider, SP, networks that are interconnected by common protocols for communication, the node configured to:

receive a request to register a particular instance of an application on a particular M2M device (150) with the registrar node (140), wherein the registration request includes access information for reaching that particular instance from the perspective of an underlying network (1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; and

retrieve instance-specific information that defines operations that the M2M SP network (170) authorizes said particular instance of the application to perform, by sending a request for the instance-specific information to an infrastructure node

(130), the request including said access information and said application identifying information.

30. The registrar node (140) of claim 29 configured to implement the method of any of claims 13-24.

31 . A computer program, comprising instructions which, when executed on at least one processor of a node, cause the at least one processor to carry out the method according to any one of claims 1 to 24.

32. A carrier containing the computer program of claim 31 , wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

33. An infrastructure node (130) in one of a plurality of machine-to-machine, M2M, service provider, SP, networks that are communicatively interconnected by common protocols, the infrastructure node (130) characterized by:

a first module configured to receive a request for instance-specific information that is associated with a particular instance of an M2M application on a particular M2M device (150), and wherein the request includes access information for reaching that particular instance from the perspective of an underlying network

(1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; a second module configured to, based on the access information, retrieve from the underlying network (1 10) a common identifier that identifies the particular M2M device (150) to both the M2M SP network (170) and the underlying network (1 10); and

a third module configured to identify the requested instance-specific information based on the common identifier and the application identifying information.

34. An inter-working node (120) in an underlying network (1 10), the underlying network (1 10) configured to provide data transport services for a machine-to-machine, M2M, service provider, SP, network, the interworking node characterized by:

a first module configured to receive a request from an infrastructure node (130) in the M2M SP network (170) for a common identifier that identifies a particular M2M device (150) to both the M2M SP network (170) and the underlying network (1 10), wherein the request includes access information for reaching a particular instance of an application on particular M2M device (150) from the perspective of the underlying network (1 10);

a second module configured to retrieve the common identifier, based on a mapping by the underlying network (1 10) between the common identifier and the access information; and

a third module configured to send the common identifier to the infrastructure node (130) as a response to the request.

35. A registrar node (140) apparatus in one of a plurality of machine-to-machine, M2M, service provider, SP, networks that are communicatively interconnected by common protocols, the registrar node (140) characterized by:

a first module configured to receive a request to register a particular instance of an application on a particular M2M device (150) with the registrar node (140), wherein the registration request includes access information for reaching that particular instance from the perspective of an underlying network (1 10) that provides data transport services for the M2M SP network (170) and further includes application identifying information that identifies the application; and a second module configured to retrieve instance-specific information that is associated with a particular instance of an M2M application on a particular M2M device (150), by sending a request for the instance-specific information to an infrastructure node (130), the request including said access information and said application identifying information.