WO2013073747A1

WO2013073747A1 - M2m communication via another scl

Info

Publication number: WO2013073747A1
Application number: PCT/KR2012/001598
Authority: WO
Inventors: Dragan Vujcic; Jean-Francois Deprun
Original assignee: Lg Electronics Inc.
Priority date: 2011-11-14
Filing date: 2012-03-05
Publication date: 2013-05-23

Abstract

The present document is directed to a method for a device to transmit data of an application to a network via another SCL (service capability layer) not having the SCL base resource supporting the application, and a device to perform the same. The method comprises transmitting the data via a first service capability layer (SCL) of the device to the network, wherein the first SCL has a SCL base resource supporting the specific application; and transmitting the data via a second SCL of the device not having the SCL base resource supporting the specific application to the network, when transmitting the data via the first SCL is not successful, wherein the SCL base resource of the second SCL is updated to support the specific application. Device is configured to perform the method.

Description

M2M COMMUNICATION VIA ANOTHER SCL

The present document is directed to a M2M (Machine to Machine) communication technology. More specifically, the present document is directed to a method for a device to transmit data of an application to a network via another SCL (service capability layer) not having the SCL base resource supporting the application, and a device to perform 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 high level architecture for M2M as specified by ETSI.

Referring to figure 2, when a user wants to initiate an application (e.g. smart metering application), the user can put this information through a user interface to application e.g. web portal interface (using monitoring, user preference, etc). The application has a mIa interface with ETSI M2M service capability layer, and the ETSI M2M service capability layer has a mId interface with M2M service capability layer of the device. The mId interface allows a M2M Service Capabilities residing in a M2M Device or M2M Gateway to communicate with the M2M Service Capabilities in the Network Domain and vice versa. mId uses core network connectivity functions as an underlying layer.

M2M service capability layer in the M2M gateway or in the M2M device has a dIa interface with M2M application in the device. In this procedure, the M2M service credentials (e.g. M2M IDs, M2M keys, etc…) are either pre-provisioned, stored by default into the device (device memory) or provisioned from the access network, i.e in UICC (Universal Integrated Circuit Card) based on the a business relationship between the Access Network Provider and the M2M Service Provider.

The above mentioned 3 interfaces are explained more specifically.

The mIa reference point offers generic and extendable mechanism for Network Applications interactions with the NSCL. The mIa reference point, between NA and NSCL, shall support the procedures for the following functions, which include:

Registration of NA to the NSCL.

Request to Read/Write, subject to proper authorization, information in the NSCL, GSCL, or DSCL.

Request device management actions (e.g. software upgrade, configuration management).

Subscription and notification to specific events.

Request the creation, deletion and listing of group(s).

The dIa reference point offers generic and extendable mechanism for Device Application (DA)/Gateway Application (GA) interactions with the DSCL/GSCL. The dIa reference point, between DA/GA and DSCL/GSCL, shall support the procedures for the following functions, which include:

Registration of DA/GA to GSCL.

Registration of DA to DSCL.

Request the creation, deletion and listing of group(s).

The mId reference point offers generic and extendable mechanism for SCL interactions. The mId reference point, between SCLs, shall support the procedures for the following functions which include:

Registration of a DSCL/GSCL to NSCL.

Subscription and notification to specific events.

Request the creation, deletion and listing of group(s).

Provides security related features.

Figure 3 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 3, 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 a 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 4 shows relationship between keys used for different levels of authentication and authorization.

In figure 4, 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. Thus, transmission of data for a specific application can be served only by the SCL having the base resource supporting the application. However, this view limits the flexibility of the M2M, since only one SCL can be used per application.

Therefore, the present proposal is directed to M2M communication via a Service Capability Layer (SCL) not having the base resource supporting the application. However, according the proposal, the base resource of the SCL is updated by the request of the SCL previously having the base resource supporting the application.

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 transmit data of a specific application to a network, the method comprising: transmitting the data via a first service capability layer (SCL) of the device to the network, wherein the first SCL has a SCL base resource supporting the specific application; and transmitting the data via a second SCL of the device not having the SCL base resource supporting the specific application to the network, when transmitting the data via the first SCL is not successful, wherein the SCL base resource of the second SCL is updated to support the specific application is proposed.

Here, the specific application may be shared by the first and the second SCLs, when the SCL base resource of the second SCL is updated to support the specific application.

The SCL base resource of the second SCL may be updated by a request of the first SCL.

In one embodiment, root configuration information may be used to support a first SCL base resource for the first SCL and a second SCL base resource for the second SCL.

The root configuration information may comprise configuration information and SCL base resources including the first and the second SCL base resources, and the configuration information may comprise mapping information between applications and the SCL base resources.

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 transmit data of a specific application to a network, the device comprising: one or more communication modules for transmitting and receiving the data; and a processor connected to the communication modules and supporting a first and a second service capability layers (SCLs), wherein the processor is configured to control the communication modules to transmit the data to the network via the first SCL having a SCL base resource supporting the specific application, wherein the processor is further configured to control the communication modules to transmit the data to the network via the second SCL not having the SCL base resource supporting the specific application, when transmission of the data via the first SCL is not successful, and wherein the SCL base resource of the second SCL is updated to support the specific application is proposed.

The specific application can be shared by the first and the second SCLs, when the SCL base resource of the second SCL is updated to support the specific application.

In one embodiment, root configuration information can be used to support a first SCL base resource for the first SCL and a second SCL base resource for the second SCL.

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, M2M communication via a Service Capability Layer (SCL) not having the base resource supporting the application can be implemented.

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 high level architecture for M2M as specified by ETSI;

Figure 3 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 4 shows relationship between keys used for different levels of authentication and authorization;

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

Figure 6 is for explaining the procedure of exchanging information between DA/GA and NA;

Figure 7 shows an overview of the M2M device;

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

Figure 9 is for showing the concept of the preferred embodiment of the present invention;

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

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

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, the present proposal is directed to a method for a device to transmit data of an application to a network via another SCL. To aid the understanding of the proposal, the following is for introducing the main types of resource used in a SCL.

Figure 5 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 5.

As shown in figure 5, 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.

Based on this, the procedure for exchanging information between M2M applications.

Figure 6 is for explaining the procedure of exchanging information between DA/GA and NA.

This procedure is based on the procedures adopting a RESTful architecture style. This style governs how M2M Applications (DA, GA, NA) and/or M2M SCL are exchanging information with each other. The properties of a RESTful style are not described here. A RESTful architecture is about the transfer of representations of uniquely addressable resources. ETSI M2M standardized the resource structure that resides on a SCL.

In a very simplistic view, imagine that certain resources are buckets that can hold some application specific data. These buckets - as far as the scope of an M2M service layer is concerned - reside in the respective SCL. The buckets have certain properties and are structured. To illustrate a very basic use of this mediator function of the M2M SCL, a simple example shall be described here.

An application (DA) on an M2M Device that is not always connected may want to send some data to another application (NA) on the network by means of the M2M SCL. In this case, as shown in figure 6, DA would write data to a resource in the NSCL and NA would read that resource. If configured accordingly, the NA could also be notified by the NSCL upon the writing (update) of the resource by the DA, in order to facilitate synchronization between DA and NA. Figure 6 meant to illustrate that process of the data flow and not the operation flow.

Figure 7 shows an overview of the M2M device.

In figure 7, 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 7, 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 6, 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 7, until now, there is one SCL per device with several applications. This may limits the possibility of M2M device having multiple service providers.

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

As shown in figure 8, 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 7) 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 9 is for showing the concept of the preferred embodiment of the present invention.

As shown in figure 9, the present proposal assumes that several SCLs are present per device, each of which serves several applications. For the example of figure 9, the SCL 1 has the SCL base resource for supporting the application 1. SCL 1 uses

capabilities

1 and 2, and SCL 2 uses

capabilities

3 and 4. Capability 1 can be exemplified as 3G network access capability, and capability 3 can be exemplified as WiFi network access capability.

When the application 1 needs to send data using the capability 3 (e.g. WiFi network access capability), the application 1 has to transmit the data to SCL 1. It is because SCL 2 has no SCL base resource for supporting the application 1. Then, SCL 1 may request SCL 2 to transmit the data instead of SCL 1. During this, the SCL base resource of the SCL 2 may be updated to support the application 1. This update may require the communication between the NA (network Application) and/or NSCL (Network SCL). And, this update procedure may include procedure for establishing the security key authentication, etc.

According to one example of the proposal, this update procedure may be for temporary service for the data communication. After transmitting data via SCL 2, the update for normal service may be performed.

The above proposal can be developed as a shared application concept. This concept is explained.

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

As shown in figure 10, 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. This can be achieved through the procedure explained with regards to figure 9.

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 10, 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).

To assist these concepts, one embodiment of the present invention 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.

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.

In figure 11, 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

Using this concept of a root configuration for supporting multiple components, the device may support multiple SCLs and the same application can be served by different SCLs.

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 transmit data of a specific application to a network, the method comprising:

transmitting the data via a first service capability layer (SCL) of the device to the network, wherein the first SCL has a SCL base resource supporting the specific application; and

transmitting the data via a second SCL of the device not having the SCL base resource supporting the specific application to the network, when transmitting the data via the first SCL is not successful,

wherein the SCL base resource of the second SCL is updated to support the specific application.
The method of claim 1, wherein the specific application is shared by the first and the second SCLs, when the SCL base resource of the second SCL is updated to support the specific application.
The method of claim 1, wherein the SCL base resource of the second SCL is updated by a request of the first SCL.
The method of claim 1, wherein root configuration information is used to support a first SCL base resource for the first SCL and a second SCL base resource for the second SCL.
The method of claim 1, wherein the root configuration information comprises configuration information and SCL base resources including the first and the second SCL base resources,

wherein the configuration information comprises mapping information between applications and the SCL base resources.
A device configured to transmit data of a specific application to a network, the device comprising:

one or more communication modules for transmitting and receiving the data; and

a processor connected to the communication modules and supporting a first and a second service capability layers (SCLs),

wherein the processor is configured to control the communication modules to transmit the data to the network via the first SCL having a SCL base resource supporting the specific application,

wherein the processor is further configured to control the communication modules to transmit the data to the network via the second SCL not having the SCL base resource supporting the specific application, when transmission of the data via the first SCL is not successful, and

wherein the SCL base resource of the second SCL is updated to support the specific application.
The device of claim 6, wherein the specific application is shared by the first and the second SCLs, when the SCL base resource of the second SCL is updated to support the specific application.
The device of claim 6, wherein the SCL base resource of the second SCL is updated by a request of the first SCL.
The device of claim 6, wherein root configuration information is used to support a first SCL base resource for the first SCL and a second SCL base resource for the second SCL.
The device of claim 6, wherein the root configuration information comprises configuration information and SCL base resources including the first and the second SCL base resources,

wherein the configuration information comprises mapping information between applications and the SCL base resources.