WO2013051770A1

WO2013051770A1 - Component generation based on root configuration information for new m2m application

Info

Publication number: WO2013051770A1
Application number: PCT/KR2012/001658
Authority: WO
Inventors: Dragan Vujcic; Jean-Francois Deprun
Original assignee: Lg Electronics Inc.
Priority date: 2011-10-05
Filing date: 2012-03-07
Publication date: 2013-04-11

Abstract

The present document is directed to a method for a device to generate an additional component for an additional application not served by an existing component based on newly defined root configuration information, and device to configure the same. The method comprises transmitting a request message comprising information for the additional application to a network; receiving an update message comprising the information for the additional application and information for the additional component for the additional application from the network, wherein the information for the additional component is made based on root configuration information comprising resource information for multiple components; and generating the additional component to support the additional application. The device is configured to perform the method.

Description

COMPONENT GENERATION BASED ON ROOT CONFIGURATION INFORMATION FOR NEW M2M APPLICATION

The present document is directed to M2M (Machine to Machine) communication technology. More specifically, the present document is directed to a method for a device to generate an additional component for an additional application not served by an existing component based on newly defined root configuration information, and device to configure the same.

Machine to Machine (M2M) Communication is seen as a form of data communication between entities that do not necessarily need human interaction. It is different to current communication models as it involves new or different market scenarios. M2M bears enormous application diversity, below is some application domain example :

- Security:

Alarm systems, backup for landline, access control, car/driver security, etc.

- Metering:

Power, gas, water, heating, grid control, etc…

- Health:

Monitoring vital signs, supporting the aged or handicapped, web access telemedicine points, remote diagnostics, etc.

- Tracking & Tracing:

Fleet management, order management, pay as you drive, asset tracking, navigation, traffic information, etc.

- Payment:

Vending machines, gaming machines, point of sales, etc…

- Etc.

Figure 1 provides the key elements of M2M Domain:

Referring to Figure 1, the M2M Device Domain is a M2M area that provide connectivity between M2M Devices and M2M Gateways, e.g. Personal Area Network technologies such as IEEE 802.15, SRD, UWB, Zigbee, Bluetooth, etc, or local networks such as PLC, M-BUS, Wireless M-BUS.

M2M Device is a device capable of replying to requests (or transmitting) for data contained within those devices autonomously. Such devices run M2M applications using M2M Service Capabilities. They can be connected to the Network domain either directly via the access network(s) or via M2M gateway(s) as e network proxy.

M2M Gateways use M2M capabilities to ensure M2M Devices inter working and interconnection to the communications network (Network Domain).

In figure 1, the M2M Core Network Domain provides connectivity between the M2M Device(s)/Gateway(s) and M2M application (server). It can be further split into Access transport and Core networks, e.g.: xDSL, PLC, satellite, LTE, GERAN, UTRAN, eUTRAN, W-LAN, WiMAX, etc.

M2M Application Domain (Server) contains the middleware layer where data goes through various application services and is used by the specific business-processing a software agent, or process by which the data can be analyzed, reported, and acted upon.

Figure 2 provides the mapping of reference points dIa, mId and mIa interfaces to the different deployment scenarios that are supported by the current release of the specification.

In Figure 2, gateway (G) shall provide Gateway M2M Service Capabilities (GSCL) that communicates to the Network M2M Service Capabilities NSCL using the mId reference point and to Device Application (DA) or Gateway Application (GA) using the dIa reference point.

Device (D) shall provide Device M2M Service Capability (DSCL) that communicates to an Network M2M Service Capabilities NSCL using the mId reference point and to device application (DA) using the dIa reference point.

Device' (D') shall host DA that communicates to a GSCL using the dIa reference point. D’ does not implement ETSI M2M Service Capabilities.

Another important aspect is that the Secured Environment is required for each of above domains. Service Capability Layer credentials, such as permanent identifiers and root keys are provisioned to M2M Device. These credentials are required by the M2M Service Bootstrap procedure to configure the M2M Device with initial mutual authentication and secure communication between Device Service Capability Layer (DSCL) on the M2M Device and M2M Service Capability Layer in the network (NSCL), as well as authorization to access specific M2M Services and related accounting/billing functionality.

The M2M Device security capability should provide functionalities to support service bootstrapping, key hierarchy realization for authentication and authorization. The following describes keys used for different levels of Authentication and Authorization in current M2M architecture.

Figure 3 shows relationship between keys used for different levels of authentication and authorization.

In figure 3, Kr represents a root key. The root key is pre-provisioned and stored within a Secured Environment of the M2M Device. It is coupled with a unique M2M Device and M2M Service Provider. It is used for mutual authentication and key agreement between the M2M Device and the M2M Service Provider, Kr is also used for deriving a service key (Ks) through authentication and key agreement between the M2M Device and the M2M Service Capabilities at the Network domain.

And, Ks represents a service key. The service key is derived from Kr, upon successful mutual authentication of the device. Ks is used for generating Ka keys (applications keys). Ks is used for secure communication between Device Service capability layer (DSCL) and the M2M Service provider/Network Service capability layer(NSCL).

Finally, Ka represents a M2M Application key. Ka is used as symmetric shared secret for setting up secure application data sessions authorized applications. Ka keys are derived from Ks, after successful mutual authentication between M2M Device/and M2M Service Provider. Ka is used for authentication and authorization of M2M Applications at the M2M Device and for protection of application data traffic.

According to current specification of ETSI, there is one SCL per device with several applications. For example, Ka1, Ka2, .. come from Ks1, Ks2, … from Kr1. SCL is owned by a service provider. This view limits the possibilities of the M2M, since only one service provider can be used per a device.

In the future, it is highly probable that the same device has several service providers. In this regards, new resource structure is needed to support this.

Accordingly, the present invention is directed to propose newly defined root configuration information, methods for a device to generate an additional component for an additional application not served by an existing component based on the newly defined root configuration information, and devices to configure the same.

Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a method for a device to generate an additional component for an additional application not served by an existing component, the method comprising: transmitting a request message comprising information for the additional application to a network; receiving an update message comprising the information for the additional application and information for the additional component for the additional application from the network, wherein the information for the additional component is made based on root configuration information comprising resource information for multiple components; and generating the additional component to support the additional application is proposed.

Here, the additional component may comprise at least one of a service capability layer (SCL) entity, a M2M (Machine to Machine) node and application.

The root configuration information may comprise (a) multiple SCL base resources and (b) configuration information for the multiple SCL base resources.

Preferably, the root configuration information can be updated to include a specific SCL base resource for the additional application and to add information for the specific SCL base resource to the configuration information.

One embodiment of the present invention, receiving the update message may comprise: receiving, from the network, a first update message to make the device to download the additional application; transmitting, to the network, a first response message informing the network that the additional application is not served by the existing component of the device; receiving, from the network, a request message requesting information for the device; transmitting, to the network, a second response message informing the network the information for the device, wherein the root configuration information of the network is updated based on the information for the device; and receiving, from the network, a second update message comprising the information for the additional application and the information for the additional component for the additional application from the network. In this embodiment, the information for the device may comprise at least one of a device type and device characteristics (e.g. Laptop, desktop, cellular etc.).

In another embodiment of the present invention, transmitting the request message may comprise: selecting the additional application; creating a temporary component for the additional application; updating the root configuration information of the device to include information about the temporary component; and transmitting the request message. In this embodiment, receiving the update message may comprise: receiving, from the network, a first update message to make the device to download the additional application; transmitting, to the network, a response message informing the network of the updated root configuration information; and receiving, from the network, a second update message comprising the information for the additional application and the information for the additional component for the additional application from the network.

According to still another embodiment of the present invention, the network may comprise a first network service capability layer (NSCL 1) having information for the device, and the network may comprises a second NSCL (NSCL 2) communicating with the device for the additional application. In this situation, the first NSCL may provide the information for the device to the second NSCL, and the update message can be received from the second NSCL.

Preferably, the method can further comprise: installing the additional application before transmitting the request message; and the information for the additional application may comprise authorization information to use the additional application.

To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a device configured to generate an additional component for an additional application not served by an existing component, the device comprising: a communication module configured to transmit a request message comprising information for the additional application to a network, and to receive an update message comprising the information for the additional application and information for the additional component for the additional application from the network; and a processor connected to the communication module, and configured to generate the additional component to support the additional application, wherein the information for the additional component is made based on root configuration information comprising resource information for multiple components is proposed.

Here, the additional component may comprise at least one of a service capability layer (SCL) entity, a M2M (Machine to Machine) node and an application.

In one embodiment, the processor can be further configured to: transmit a first response message, by the communication module, informing the network that the additional application is not served by the existing component of the device, when a first update message to make the device to download the additional application is received from the network by the communication module without the information for the additional component for the additional application, and transmit a second response message, by the communication module, informing the network the information for the device, when a request message requesting information for the device is received from the network by the communication module, wherein the root configuration information of the network is updated based on the information for the device. In this case, the information for the device may comprise at least one of a device type and device characteristics.

In another embodiment, the processor can be further configured to select the additional application; create a temporary component for the additional application; and update the root configuration information of the device to include information about the temporary component, before transmission of the request message. The processor still can be further configured to transmit, to the network by the communication module, a response message informing the network of the updated root configuration information, when the communication module receives, from the network, a first update message to make the device to download the additional application without the information for the additional component.

Still according to another embodiment, the network may comprise a first network service capability layer (NSCL 1) having information for the device, and the network may comprise a second NSCL (NSCL 2) communicating with the device for the additional application. In this situation, the first NSCL may provide the information for the device to the second NSCL, and the update message may be received from the second NSCL.

The processor can be further configured to install the additional application before transmitting the request message, and the information for the additional application may comprise authorization information to use the additional application.

It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

According to the present invention, efficient method for the same device having several service providers is provided.

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principle of the invention. In the drawings:

Figure 1 provides the key elements of M2M Domain;

Figure 2 provides the mapping of reference points dIa, mId and mIa interfaces to the different deployment scenarios that are supported by the current release of the specification;

Figure 3 shows relationship between keys used for different levels of authentication and authorization;

Figure 4 is for introducing the main types of resource used in a SCL;

Figure 5 shows an overview of the M2M device;

Figure 6 shows the concept of a device having multiple service providers;

Figure 7 shows another concept of a device in which one application is shared with 2 or more SCLs;

Figure 8 shows a concept of a root configuration for supporting multiple components;

Figure 9 shows a process for generating an additional component for an additional application not served by an existing component;

Figure 10 shows a detailed procedural example according to one embodiment of the present invention;

Figure 11 shows another detailed procedural example according to one embodiment of the present invention; and

Figure 12 shows still another detailed procedural example according to one embodiment of the present invention.

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. In the following detailed description of the invention includes details to help the full understanding of the present invention. Yet, it is apparent to those skilled in the art that the present invention can be implemented without these details. For instance, although the following detailed description is made in detail on the assumption that a mobile communication system is based on ETSI system, it is applicable to other prescribed mobile communication systems by excluding unique items of the ETSI system.

Occasionally, the structures and devices known to the public are omitted to avoid vagueness of the present invention or can be illustrated as block diagrams centering on their core functions.

As stated above, it is highly probable that the same device has several service providers. To meet this need, efficient resource structure for the M2M communication is necessary.

Figure 4 is for introducing the main types of resource used in a SCL.

Since all the main types of resource used in a SCL will have to be addressed in some way and since there are relationships between them (like a parent-child containment relationship), a hierarchical tree structure for modeling their structure and relationships is presented in figure 4.

As shown in figure 4, the sclBase resource shall contain all other resources of the hosting SCL. A sclBase resource is the root of all other resources it contains. The sclBase resource shall represented by an absolute URI (uniform Resource Identifier). All other resources hosted in the SCL shall also be identified by a URI.

The <sclBase> shall contain the sub resources based on the multiplicity indicated in the below table:

Table 1

subResource	Multiplicity	Description
Scls
	1	Collection of <scl> resources each representing a remote SCLs with which the hosting SCL is registered to or that is registered with the hosting SCL.
applications	1	Collection of <application> resources which are registered the hosting SCL represented by the <sclBase> resource.
containers	1	Collection of <container> resources that do not have a containment relation with a specific remote entity (Application or SCL). This means that if the entity that created a <container> in this collection is deleted, the <container> shall not be deleted.This collection contains local <container> resources (representing local containers created by local or remote entities).
accessRights	1	Collection of <accessRight> resources that do not have a containment relation with a specific remote entity (Application or SCL). This means that if the entity that created an <accessRight> in this collection is deleted, the <accessRight> shall not be deleted.
subscriptions	1	Collection containing all active subscriptions for the <sclBase> resource.
discovery	1	Resource used for resource discovery.

Several Identifiers are specified as following:

An Application Identifer, App-ID, uniquely identifies an M2M Application (NA, GA, DA, D’A) that is registered with a SCL. An App-ID is used to identify an application for the purpose of interacting with the application. This identifier shall be globally unique. Ka is associated with this ID.

A M2M Node is a logical representation of the M2M components in the M2M Device, M2M Gateway or the Network. Such components are one SCL and its related applications. It is owned by the M2M service provider. An M2M Node is identified by a globally unique identifier, the M2M-Node-ID. Kr is associated with this ID.

A SCL shall be identified by a globally unique identifier, the SCL-ID.

An M2M Connection is the connection between the M2M Device/M2M Gateway and the NSCL and it is used for facilitating the SCLs and applications on both ends to communicate with each other. An M2M Connection is identified by an M2M-Connection-ID. KS is associated with this ID.

Figure 5 shows an overview of the M2M device.

In figure 5, the M2M device has M2M platform or M2M layer and other components are employed based on it. The device has device ID and it is associated with Kr1. As shown in figure 5, the M2M device has M2M node 1 having M2M node ID 1. Also, the M2M device has a SCL (SCL 1) having SCL-ID 1. The SCL-ID 1 is associated with Ks1. Ks1 is derived from Kr1.

The SCL may support multiple capabilities for multiple applications. In figure 5, the SCL 1 supports

capabilities

1 and 2 for

applications

1 and 2. Ka1 and Ka2 are for

applications

1 and 2, respectively, and they are generated based on Ks1.

As shown in figure 5, until now, there is one SCL per device with several applications. This may limits the possibility of M2M device having multiple service provider.

Figure 6 shows the concept of a device having multiple service providers.

As shown in figure 6, each of the multiple Service Providers may have its own SCL, and each SCL may have applications. That is, the device may have 2 or more M2M nodes (

nodes

1 and 2 in figure 6) and each of the nodes has its own SCL (SCLs 1 and 2). SCL 1 may have

applications

1 and 2, and SCL 2 may have

applications

3, 4 and 5.

Figure 7 shows another concept of a device in which one application is shared with 2 or more SCLs.

As shown in figure 7, it will be possible to have the same application with different SCL or M2M node. In this example, application 3 belongs to 2 different M2M nodes. One from the SCL1 and the other from the SCL2.

A possible use case is like this: The customer wants to pay some goods with his banking application 3 and he wants to pay its petrol with his banking application 3. It is the same application but there are 2 service providers. 2 different keys are used: Ka3 for the first bank, Ka6 for the second bank.

As shown in figure 7, application 3 with Ka3 is served by SCL 1, and application 3 with Ka6 is served by SCL 2. That is, the same application can be served by different SCLs for different service provider (first bank and second bank).

Also the users or/and a Service Provider can add or remove applications. The management of the keys and their links with Applications and SCL have to be done efficiently.

Until now, there are no process to add or remove SCL, M2M Nodes or/and Applications. Therefore, one aspect of the present invention is to define schemes to add information in the SclBase to allow the possibility to have several keys and IDs for the same entity. Another aspect of the present invention is for the creation of the key and ID in function of the relationships between Network Operator, Service Provider and Applications Provider. Also, another aspect of the present invention is to create process to add and remove Application, M2M node and SCL.

First step to this end is directed to newly define a resource structure for the possibility to save several Keys and IDs for the same application/M2M node/SCL. ETSI standard is defined such that it cannot allow having several keys for the same ID. As stated above, the M2M information of the device is stored in the sclBase. Thus, this sclBase cannot allow storing multiple Keys.

Keys are stored and used in a secure environment. Then, commands will be used based on keys. An example could be:

CMD-Encrypt(APP-ID/SCL-ID/other-ID; Confidentiality/Integrity/Availability/Authenticity/Non-repudiation; data)

The sclBase resource shall contain all other resources of the one SCL. If several SCL exists, several sclBase are needed. Thus, one embodiment of the present invention proposes to define and use the following resource structure.

Figure 8 shows a concept of a root configuration for supporting multiple components.

In figure 8, there are “m” SCL; one sclBase is for one SCL. The <configuration> resumes the IDs of all the SCL and applications belong to sclBase(s). It can allow to find the owner of Application and SCL in functions of their ID.

As previous explanations, an application can belong to several SCLs. In this case, these SCLs are linked with applications in the <configuration>.

The < Configuration > resource shall contain all the ID of the SCL and Applications as in the following tables.

Table 2

subResource	Multiplicity	Description
SCL	n	Identifier of the SCL (see [SCL-ID])
Applications	n	Identifier of the applications (see [Application-ID])

Table 3

AttributeName	Mandatory/Optional	Type	Description
SCL-ID	M	RW	List of sclBases own the SCL
Applications-ID	M	RW	List of SCLs own the applications

The above concept of a root configuration for supporting multiple components is associated with the second step of the present invention. That is, the second step of the present invention is directed to create the Key and/or the ID following several ways in a function of the relationships between Network Operator, Service Provider and Application Provider. By using the above proposed root configuration the Key and/or the ID can be created in a function of the relationships between Network Operator, Service Provider and Application Provider.

The third step of the present invention is associated with specifying the process for creating/removing/adding/updating SCL/Node/Applications.

Figure 9 shows a process for generating an additional component for an additional application not served by an existing component.

As shown in figure 9, the device may transmit a request message comprising information for the additional application to a network (S910). The request message may comprise at least one of an ID of the additional application, an ID of the device, and an ID of a user or an event. This message may be transmitted to a NA (Network Application).

Network may respond to this request by transmitting an update message comprising the information for the additional application and information for the additional component for the additional application (S910). The information for the additional component can be made based on root configuration information comprising resource information for multiple components. That is, the information for the additional component can have the structure as shown in figure 8. Thus, the root configuration information may comprise (a) multiple SCL base resources and (b) configuration information for the multiple SCL base resources. And, the root configuration information may be updated to include a specific SCL base resource for the additional application and to add information for the specific SCL base resource to the configuration information.

Based on the received information, the device may generate the additional components to support the additional application (S930 ? S950). The additional component may comprise at least one of SCL entity, a M2M node and application.

There may be options for the sequence of generating entities. The M2M device domain comprises DA (Device Application), DSCL (Device SCL) and one or more communication modules. Also, DA and DSCL can be employed within a communication node. Thus, when generating entities for additional application, one may think of generating application, then SCL, and communication node for the same.

However, the preferred example of the present embodiment proposes to generate a communication node first, then generate a SCL for the communication node, and finally generate the additional application for the SCL of the communication node, as shown in figure 9. Since the present embodiment is for adding new application which does not have credentials pre-provisioned by default, and for a situation when there are no business relationships between the access Network provider and the M2M service provider. Thus, by generating the entities from node, SCL and application, we can stably establish keys to be used for these entities.

Followings are for the detailed examples of the above embodiment.

Figure 10 shows a detailed procedural example according to one embodiment of the present invention.

First, an application is selected by a user/external event (001). The User/External Event may send a request the DA/GA (002). The DA/GA may forward this information to its NA (003).

The NA may contact the NSCL with device information and application information (004). The NSCL may contact the device and try to download the application (005). However, the present embodiment is for the case when the target application is not supported by the existing components. Thus, the device may answer with an error because it does not has the right characteristics to support the application (006).

Then, the SCL may ask for more information about the device (007). The device may send its characteristics (008). Based on this, the SCL may select/adapt the right application, Service Capabilities, etc (009). At this point, the root configuration can be used.

The SCL may send the package to the device (application, Service Capabilities, M2M software..) (010). Based on this, the device may update its software and configuration (011).

After the above procedure, the Authentication can be done and a M2M session can start.

Figure 11 shows another detailed procedural example according to one embodiment of the present invention.

As the example of figure 10, an application is selected by user/external event (001). The User/External Event may send the request for the selected application to the DA/GA (002).

In this example, the device may inform User/External Event it has no M2M configuration for the target application (003). Then, the User/External Event may send a M2M configuration with Application information (004). Based on this, the device may create a M2M platform (005). Then, the device may contact the NA (006).

In response, the NA may contact the NSCL with device information and application information (007). The NSCL contacts the device and inform it about the application which shall be downloaded (008). The device may answer with M2M applications information (009). This information comes from User/External Event (see step 4).

With this information, the NSCL may select/configures the Application (with M2M software if needed) (010). Then, the NSCL may send the application (with M2 software if needed) to the Device (011). Based on this, the device may update/create the application (012). The device has now the right configuration and can start the authentication/bootstrap with the NSCL (013).

In this particular example, it is supposed that the device has already a NSCL and a M2M platform. The authentication has already done with a NSCL (001).

With this assumption, an application is selected by a user/external event (002). The User/External Event may send the request to the DA/GA (003). The device may forward the request to create an application to its NSCL (004). This NSCL (NSCL1) may forward the request to the NA (005).

The NA has a business model with the NSCL2. Thus, the NA can send a request to this NSCL to allow the update of the device with the NSCL2 configuration (006). Then, the NSCL2 may contact the NSCL1 to have information about the bootstrapping and M2M parameters (007). The NSCL1 may send the required information for the M2M communication with the device to the NSCL2 (008).

With this information, the NSCL2 can communicate with the DA/GA. The NSCL2 can update the application of the device and also configure a new M2M session (009). Then, the device can update its M2M configuration and application and can start a M2M session with the NSCL2 (010). At this moment the M2M configuration of the device supports 2 M2M NSCL.

After the creation/update of the M2M Platform, a sclbase is created/updated. Each SCL shall be synchronized with its SCL.

The above-described enhanced random access technology and apparatus are explained mainly with reference to the example that they are applied to the ETSI system. However, they are applicable to various mobile communication systems.

Claims

A method for a device to generate an additional component for an additional application not served by an existing component, the method comprising:

transmitting a request message comprising information for the additional application to a network;

receiving an update message comprising the information for the additional application and information for the additional component for the additional application from the network, wherein the information for the additional component is made based on root configuration information comprising resource information for multiple components; and

generating the additional component to support the additional application.
The method of claim 1, wherein the additional component comprises at least one of a service capability layer (SCL) entity, a M2M (Machine to Machine) node and an application.
The method of claim 2, wherein the root configuration information comprises (a) multiple SCL base resources and (b) configuration information for the multiple SCL base resources.
The method of claim 3, wherein the root configuration information is updated to include a specific SCL base resource for the additional application and to add information for the specific SCL base resource to the configuration information.
The method of claim 3, wherein receiving the update message comprises:

receiving, from the network, a first update message to make the device to download the additional application;

transmitting, to the network, a first response message informing the network that the additional application is not served by the existing component of the device;

receiving, from the network, a request message requesting information for the device;

transmitting, to the network, a second response message informing the network the information for the device, wherein the root configuration information of the network is updated based on the information for the device; and

receiving, from the network, a second update message comprising the information for the additional application and the information for the additional component for the additional application from the network.
The method of claim 5, wherein the information for the device comprises at least one of a device type and device characteristics.
The method of claim 3, wherein transmitting the request message comprises:

selecting the additional application;

creating a temporary component for the additional application;

updating the root configuration information of the device to include information about the temporary component; and

transmitting the request message.
The method of claim 7, wherein receiving the update message comprises:

receiving, from the network, a first update message to make the device to download the additional application;

transmitting, to the network, a response message informing the network of the updated root configuration information; and

receiving, from the network, a second update message comprising the information for the additional application and the information for the additional component for the additional application.
The method of claim 3, wherein the network comprises a first network service capability layer (NSCL 1) having information for the device, and

wherein the network comprises a second NSCL (NSCL 2) communicating with the device for the additional application.
The method of claim 9, wherein the first NSCL provides the information for the device to the second NSCL, and

wherein the update message is received from the second NSCL.
The method of claim 10, further comprising:

installing the additional application before transmitting the request message; and

wherein the information for the additional application comprise authorization information to use the additional application.
A device configured to generate an additional component for an additional application not served by an existing component, the device comprising:

a communication module configured to transmit a request message comprising information for the additional application to a network, and to receive an update message comprising the information for the additional application and information for the additional component for the additional application from the network; and

a processor connected to the communication module, and configured to generate the additional component to support the additional application,

wherein the information for the additional component is made based on root configuration information comprising resource information for multiple components.
The device of claim 12, wherein the additional component comprises at least one of a service capability layer (SCL) entity, a M2M (Machine to Machine) node and an application.
The device of claim 13, wherein the root configuration information comprises (a) multiple SCL base resources and (b) configuration information for the multiple SCL base resources.
The device of claim 14, wherein the root configuration information is updated to include a specific SCL base resource for the additional application and to add information for the specific SCL base resource to the configuration information.
The device method of claim 14, wherein the processor is further configured to:

transmit a first response message, by the communication module, informing the network that the additional application is not served by the existing component of the device, when a first update message to make the device to download the additional application is received from the network by the communication module without the information for the additional component for the additional application, and

transmit a second response message, by the communication module, informing the network the information for the device, when a request message requesting information for the device is received from the network by the communication module, wherein the root configuration information of the network is updated based on the information for the device.
The device of claim 16, wherein the information for the device comprises at least one of a device type and device characteristics.
The device of claim 14, wherein the processor is further configured to select the additional application; create a temporary component for the additional application; and update the root configuration information of the device to include information about the temporary component, before transmission of the request message.
The device of claim 18, wherein the processor is further configured to transmit, to the network by the communication module, a response message informing the network of the updated root configuration information, when the communication module receives, from the network, a first update message to make the device to download the additional application without the information for the additional component.
The device of claim 14, wherein the network comprises a first network service capability layer (NSCL 1) having information for the device, and

wherein the network comprises a second NSCL (NSCL 2) communicating with the device for the additional application.
The device of claim 20, wherein the first NSCL provides the information for the device to the second NSCL, and

wherein the update message is received from the second NSCL.
The device of claim 12, wherein the processor is further configured to install the additional application before transmitting the request message, and

wherein the information for the additional application comprise authorization information to use the additional application.