KR102045907B1 - Association between application identifier and SCL identifier - Google Patents

Abstract

Provided are an M2M service providing method and an apparatus thereof. The method of providing an M2M service according to the present invention includes receiving an application registration request from an M2M application in an M2M service capability layer and including application identification information and service capability layer identification information in a service capability layer when there is no error in the received application registration request. And registering the application by creating and storing an application resource.

Description

Association method between application identification information and service providing capability identification information and apparatus therefor {Association between application identifier and SCL identifier}

The present invention relates to a method and apparatus for configuring information and apparatus for registering application identification information and M2M service providing capability identification information in providing a machine to machine communication (M2M) service.

IoT can be a process of communication between people, such as machine to machine communication (M2M), machine type communication (MTC), Internet of Thing (IOT), smart device communication, or machine oriented communication. Refers to all communication methods in which communication is performed without intervention.

The Technical Committee (TC) M2M of the European Telecommunications Standards Institute (ETSI) is promoting standardization of the functional architecture and related protocols to provide M2M services. On September 10, 2012, TC M2M published the results of the standardization work on the functional structure in the document of ETSI TS 102 690 V2.0.9 (hereinafter referred to as 'functional structure specification').

In addition, the Functional Structure Specification specifies in section 5.2.1 "Generates charging records pertaining to the use of capabilities" for charging M2M services.

In Section 10.1.2 of the Functional Structure Specification, Table 10.1 defines the 'M2M Recorded Information Elements' for charging.

Information Element For request    based triggers
Mandatory  Of optional For timer based    triggers
Mandatory  / optional Description M2M Subscription Identifier M M The M2M subscription ID associated with the request Application ID CM (when applicable) NA The M2M Application ID if applicable Receiver M NA Receiver of an M2M request (can be an NA, or D / GSCL) Issuer M NA Issuer of the M2M request (can be an NA or D / GSCL Hosting SCL O NA The hosting SCL for the request in case the receiver is not the host, where applicable Target ID M NA The target URL for the M2M request Protocol Type O NA HTTP or CoAP Primitive Type O NA Request Type Request Headers size O NA Number of bytes for the headers in the request Request Body size O NA Number of bytes of the body transported in the Request if applicable Response Headers size O NA Number of bytes for the headers in the response Response Body size O NA Number of bytes of the body transported in the Response if applicable Response code O NA Time stamp M M The time for the recording the M2M event M2M-Event-Tag M M A Tag for the M2M event for classification purposes Control Memory Size O NA Storage Memory (in bytes) s, where applicable, to store control related information associated with the recorded M2M event (excludes data storage associated with container related operations) Data Memory Size O NA Storage Memory in Kbytes, where applicable, to store data associated with container related operations Access Network Identifier O O Identifier of the access network associated with the recorded M2M event in case the request / response is carried over mId Additional Information: O Vendor specific information Occancy NA M Overall sizedimensions (in Bytes) of the containers generated by a set of application identified by the M2M Subscription Identifier

Table 1 shows the M2M Recorded Information Elements for the billing specified in Table 10.1.

The functional structure standard has not yet proposed a specific method for collecting billing information other than the billing information shown in Table 1 above.

Therefore, in order to collect the billing information specified in Table 1 without being based on the 'functional structure standard', the packet is monitored by monitoring the physical communication interface when the exchange of messages for M2M communication occurs at the mIa, mId, and dIa reference points. It should capture and store both Service Capability Layer (SCL) ID and Application ID.

However, the method of storing the SCL ID and application identification information through the physical interface monitoring has the following problems.

First, since the dIa reference point performed by a single device does not use a physical communication interface, it is impossible to monitor packets.

Second, the Server Platform or Network Service Capability Layer (NSCL) works in conjunction with numerous Device Service Capability Layers (DSCL) or Gateway Service Capability Layer (GSCL). It is practically impossible to monitor every packet sent and received at each mId reference point with numerous DSCL and GSCLs. In general, the packet monitoring method of the physical communication interface consumes a lot of CPU resources, which can seriously affect performance.

Third, after communication is terminated at the dIa, mId, and dIa reference points, neither the SCL ID nor the application ID information can be collected. That is, since the information can be collected only during the communication processing, there is a problem in that the charging information cannot be known at any time when the charging information is to be generated.

Accordingly, an object of the present invention is to provide a service providing method and apparatus for storing and managing application identification information and service capability identification information (SCL Identifier) in M2M service provision.

According to the present invention, a method of controlling the generation, inquiry, deletion, etc. of an application resource by newly defining application (or application) attribute information for associating service capability identification information and application identification information defined in ETSI.

The present invention devises a method of explicitly providing service capability layer identification information and application identification information in association with service capability layer identification information that can easily generate charging information at reference points such as dIa, mId, and mIa according to characteristics of M2M communication.

In addition, it is possible to collect charging information using application property information without monitoring the physical communication interface, and to devise a method of dramatically reducing the load on the server operated by the M2M service provider and maximizing performance.

In addition, we devise a method for providing association information between service capability layer identification information and application identification information for collecting charging information any time after M2M communication occurs.

According to the present invention, an M2M service capability layer receives an application registration request from an M2M application, and if there is no error in the application registration request, the application includes application identification information and service capability layer identification information in the service capability layer. It provides a M2M service providing method comprising the step of creating and storing resources to register the application.

In the application registration step, the application identification information hash value and the service capability layer identification information hash value may be generated for the application identification information and the service capability layer identification information, respectively. And at least one of the application identification information and the application identification information hash value and at least one of the service capability layer identification information and the service capability layer identification information hash value. In addition, the application identification information and the service capability layer identification information may be stored as an attribute of the application resource.

According to the present invention, upon receiving an application registration request from an M2M application, if there is no error in the application registration request received, the application resource including application identification information and service capability layer identification information is generated and stored to register the application. An M2M platform is provided.

In addition, according to the present invention, transmitting an application registration request from the M2M application to the M2M service capability layer; And storing the application identification information and the service capability layer identification information when the response message including the application identification information and the service capability layer identification information is received at the service capability layer with respect to the application registration request. A provision method is provided.

According to the present invention, when the application registration request is transmitted to the M2M service capability layer, and a response message including application identification information and service capability layer identification information is received at the service capability layer with respect to the application registration request, the application identification information and An M2M terminal for storing the service capability layer identification information is provided.

According to the present invention, all M2M devices, gateways, and all application identification information connected to the NSCL can be easily distinguished using a string having a predetermined length, and each application identification information and service capability layer identification information can be quickly retrieved. In addition, the association information between the application identification information and the service capability layer identification information can be known. Accordingly, the present invention has the following effects.

In collecting existing M2M billing information that is impossible or costly in the existing system, it is easy to store and manage the related information of the application identification information and the service capability layer identification information.

In addition, it is possible to retrieve or store the association information between the application identification information for generating the charging information and the service capability layer identification information at an arbitrary time impossible in the existing system.

In addition, it is possible to easily generate billing information for each SCL application that is impossible in the existing system.

1 is a view for explaining an embodiment of the structure of an M2M system to which the present invention is applied.
2 is a view showing a structure for billing prescribed in Figure 10.2 M2M functional structure standard according to an embodiment of the present invention.
3 is a diagram of Application Registration defined in Figure 5.2 of M2M functional structure specification according to an embodiment of the present invention.
4 is a flowchart illustrating a procedure of configuring linkage information between application identification information and service capability layer identification information according to the present invention.
5 is an example of an application resource according to an embodiment of the present invention.
6 is a flowchart illustrating a hash value generating method of application identification information and service capability layer identification information according to an exemplary embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In addition, in describing the present invention, if it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are only for distinguishing the components from other components, and the nature, order or order of the components are not limited by the terms. When a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected or connected to that other component, but between components It will be understood that may be "connected", "coupled" or "connected".

Embodiments of the present invention will be described based on communication of things. IoT can be used in various ways such as machine to machine communication (M2M), machine type communication (MTC), internet of things (IoT), smart device communications (SDC), or machine oriented communication (Machine Oriented Communication). Called, in the present specification will be described with respect to M2M. However, this description is not limited to M2M, but is applicable to all systems and structures that provide inter-device communication, that is, thing communication, and communication that occurs in these systems.

In addition, the IoT can be applied to various fields including smart meter, e-health, connected consumer, city automation, automotive application, and the like. .

The M2M object or apparatus in the present specification may be an M2M terminal (for example, may be an M2M standard terminal (D), an M2M non-standard terminal (d), or an M2M substandard terminal (D ′)), an M2M gateway ( G) or may be used as a higher concept including an M2M network server.

FIG. 1 is a view for explaining an example of a structure of an M2M system to which the present invention is applied and shows an M2M architecture described in an international standard, the European Telecommunication Standards Institute (ETSI) Technical Committee (TC) M2M.

Referring to FIG. 2, the M2M structure described in the International Telecommunication Standards Institute (ETSI) Technical Committee (TC) M2M standard is composed of a network domain 100 and a terminal / gateway domain 200.

The network domain 100 includes an access network 110, a core network 120, an M2M service capabilities 130, and an M2M application 140.

An access network 110 is a network that allows M2M gateways / terminals to access a core network, and includes xDSL, FTTH, Wi-Fi, and the like.

The core network 120 is an IP connection, supports roaming, and supports interworking with other networks, for example, 3GPP.

The M2M Service Capabilities 130 include functions commonly required for M2M services. Common features of M2M services provided by M2M Service Capabilities include xAE (Application Enablement), xGC (Generic Communication), xREM (Remote Entity Management), xRAR (Rechability, Addressing and Repository), xCS (Communication Selection), xSEC (Security) , 10 Service Capabilities of History and Data Retention (xHDR), Transaction Management (xTM), Interworking Proxy (xIP), and Compensation Brokerage (xCB) include M2M device 220, M2M gateway 230, and M2M server. It is a function used by the platform 130, and the M2M server platform may additionally use a telco operator exposure (TOE) function. These service functions are used through open interfaces of mId (between SCL), mIa (between NSCL and NA), and dIa (between DSCL / GSCL and DA / GA).

M2M Service Capabilities (Service Capabilities) are present in the network domain 100 and the terminal / gateway domain 200 as the M2M platform, M2M service capabilities (NSCL: Network Service Capability Layer) of the network domain is implemented in the form of a server platform, The M2M service capabilities of the terminal / gateway domain 200 may be in the form of middleware such as a terminal platform 221 (DSCL: Device Service Capability Layer) or a gateway platform 211 (GSCL: Gateway Service Capability Layer). For example, it may be implemented to reside in a terminal or a gateway.

The M2M application or application (M2M Application) is an application service that performs service logic and uses M2M service capabilities through an open interface, and exists in the network domain 100 and the terminal / gateway domain 200, respectively.

The M2M application of the network domain is generally known as a form of M2M application service 140 (NA: Network Application), and the M2M application of the terminal / gateway domain is generally a terminal app 222 (DA) or gateway app 212. (GA: Gateway Application) can reside in a gateway or a terminal to operate.

The M2M terminals 220 and 240 drive the M2M application 222 to use the functions of the network domain, so that M2M service capabilities (SC) of the M2M terminal 220 or the M2M gateway 210 (SC) 221 and 211. Can be interworked and interconnected in the network / application domain 100.

The service capability layer of the M2M terminal or the M2M gateway forms a specific interface with the service capability layer of the network domain to communicate with each other and operate.

In addition, the service capabilities of the network domain may interface with one or a plurality of core networks. In this case, the functions of the core network may be used through a known interface according to other existing standards.

To this end, according to the M2M standard structure, reference points of mIa, mId, and dIa are defined as mutual interfaces between the network domain 100 and the terminal and the gateway domain 200.

mIa is a reference point used in the network domain 100 and is an interface standard between an M2M service capability layer in the network (NSCL) 130, which is an M2M server platform, and a network application (NA) 140, which is a network application.

mId is an interface specification between the NSCL 130 of the network domain 100 and the terminal / gateway service capability (DSCL or GSCL) 211 and 221 of the terminal / gateway domain 200. That is, mId is an interface standard applied between the M2M server platform (NSCL) 130 and the M2M terminal / gateway platform (DSCL / GSCL) 221 and 211.

dIa is a reference point used in the M2M terminal / gateway domain 200, and is an interface between an M2M terminal platform (DSCL) 221 and a terminal application (DA), an M2M gateway platform (GSCL) 211, and a gateway. An interface of an application (GA), an interface specification of an M2M gateway platform 211 and a terminal application 240.

According to the present invention according to the ETSI M2M standard, data generated in an M2M device such as various sensors has a uniquely distinguishable address in a restful structure of a tree type in the form of a resource or a resource. These resources are stored and can be managed using methods defined according to the M2M standard.

The ETSI TC M2M standard defines CRUD (Create, Retrieve, Update, Delete) as a method for resource management. In other words, the Create method is used to create a resource, and the Retrieve method is used to read the contents of the resource. In addition, the Update method is used to update the contents of the resource, and the Delete method is used to delete the resource. In addition to these four methods, methods for notify and execute are defined.

A resource, on the other hand, can have one or more attributes, which are metadata about the data stored in the resource, and these values actually represent information about the content of the resource. Among the properties of a resource, there are properties that contain time information when the resource is created or modified.

The M2M application and the M2M service capability may transfer data between the M2M application and the M2M service capability by using the above-described RESTful structure format using the representation information of only defined resources.

Hereinafter, a method for charging M2M service by linking application identification information and service providing capability layer identification information according to the present invention, which is applied in the M2M environment as described above, will be described in detail with reference to the accompanying drawings.

The present invention provides an application between a Device Application (DA) and a Device Service Capability Layer (DSCL) of an M2M device to collect billing information in providing a Machine to Machine Communication (M2M) service. Provides a method of configuring information to register the information.

The present invention also provides a method of configuring information for registering DA or GA between a gateway application (GA) and a gateway service capability layer (GSCL) of the M2M gateway (dIa) for M2M service charging. .

In addition, the present invention provides a method of configuring information for registering an application between a network application (NA) and a network capability layer (NSCL) of a M2M server (mIa) for M2M service charging.

Also, how to configure the information for application registration between DSCL of M2M device and NSCL of M2M server (mId) for M2M service charging, and how to configure information for application registration between GSCL of M2M gateway and NSCL of M2M server (mId). to provide.

The association of the Application ID (Application Identifier or Application Identifier) and the SCL ID (Service Ability Layer Identifier) in Section 10.1.1 of the Functional Architecture Specification is required to collect the billing information, but is not specified in the current specification.

2 is a view showing a structure for charging defined in the M2M functional structure standard according to an embodiment of the present invention.

Referring to FIG. 2, the charging structure according to the functional structure standard includes a network domain 100, an M2M device domain 220 or an M2M gateway domain 210, and a charging server 300.

The network domain 100 includes a network application (NA) 140 and a network service capability layer (NSCL) 130. The mIa reference point is the interface through which NA and NSCL exchange information.

The device domain 220 includes a device application (DA) 222 and a device service capability layer (DSCL) 221. The dIa reference point is the interface where the DA and DSCL exchange information.

The M2M gateway 210 includes a Gateway Application (GA) 212 and an M2M Gateway Service Capability Layer (GSCL) 211. The dIa reference point is the interface through which the GA and GSCL exchange information.

Meanwhile, the mId reference point is an interface between the NSCL 130 and the DSCL 221 or an interface between the NSCL 130 and the GSCL 211.

The charging server 300 is a server for processing the charging information. The Cm reference point is an interface between the NSCL 130 and the charging server 300.

The NA provider registers the NA with the NSCL. The DA provider registers the DA with the DSCL. The GA provider registers the GA with the GSCL. The most important element to register NA, DA, GA is NSCL. NSCL is a key component to provide M2M service. It provides communication service after registering DSCL and GSCL with NSCL.

Application registration is functionally defined in the functional structure standard in Figure 5.2 of Section 5.1.2.

3 is a diagram illustrating an application registration process defined in FIG. 5.2 of M2M Functional Structure Specification 5.1.2.

Referring to FIG. 3, the application registration process of the functional structure specification section 5.1.2 specifically performs the registration process according to the procedure specified in the interface specification section 10.8.2.1 using the resources specified in the function structure specification section 9.2.3.6. .

However, the functional structure standard is defined without considering the method for collecting the charging information, and a method of linking the application identification information (Application ID) and the service capability identification information (SCL ID) necessary for charging is required.

The resources for registering the application <application> specified in Section 9.2.3.6 of the Functional Structure Specification are specified in Table 9.11 and Table 9.12. In particular, attribute information for registering an application <application> is defined in Table 9.12.

subResource Multiplicity Description containers One See clause 9.2.3.11. Contains local containers typically created by the parent application. groups One See clause 9.2.3.18. Contains local groups typically created by the parent application. accessRights One See clause 9.2.3.8. Contains local < accessRight > resources typically created by the parent application. subscriptions One See clause 9.2.3.22. notificationChannels One See clause 9.2.3.34. The collection of notification channels for use by the registered application.

Table 2 is an example of a resource for registering an application <application> stipulated in Functional Structure Specification Table 9.11.

AttributeName Mandatory / Optional Type Description expirationTime M RW See clause 9.2.2 Common attributes. This shall represent the expiration time of the registration. If the SCL does not refresh its registration before that time the resource is deleted and the application is de-registered. accessRightID O RW See clause 9.2.2 Common attributes. searchStrings M RW See clause 9.2.2 Common attributes. creationTime M RO See clause 9.2.2 Common attributes. lastModifiedTime M RO See clause 9.2.2 Common attributes. announceTo M RW See clause 9.2.2 Common attributes. aPoC O RW The Application Point of Contract is a URI that identifies how request are re-targeted. aPoCPaths O RW The aPocPaths, ifpresent, isusedtodetermineifatargetURIistobere-targeted , bydoingaprefixmatchagainsttheelementsinthepath.Eachpathcanoptionallyhavean accessRightID associatedwithit, which, ifpresent, isusedforauthorizationpurposeswhendoingthere-targeting.The accessRightID ofthebestmatchingpathprefixisusedforthispurpose.Thevalueof aPoCPaths isonlyrelevantwhenthe aPoC attributeisalsopresent. locRequestor O RW The identity of the Application to be used for the content of privacy control when requesting the location information of a remote M2M Device or Gateway.
This attribute is only used in the case that the location information is provided by a network-based location server (eg a 3GPP location server). It will be provided to the location server if the content is required for the location information retrieval.
The format of this attributed shall conform to the interface provided by the location server (eg MSISDN for a 3GPP location server).

Table 3 shows an example of a resource for registering an application <application> stipulated in Functional Structure Specification Table 9.12.

When registration of the application <application> is completed, resources as shown in Tables 2 and 3 are generated. Registration of these applications can be classified into local registration and remote registration.

Local registration is the registration of an <application> on a device with the same application and SCL as DA and DSCL or GA and GSCL. Locally registered <application> resources belong to <sclBase> / applications / <application> resources.

Remote registration is the registration of an application <application> to different devices between SCL, such as DSCL and NSCL or GSCL and NSCL. Remotely registered <application> resources belong to <sclBase> / scls / <scl> / applications / <application> resources.

4 is a flowchart illustrating a procedure of configuring linkage information between application identification information (Application ID) and service capability layer identification information (SCL ID) according to the present invention.

Referring to FIG. 4, DA / GA / NA corresponds to a device application, a gateway application, and a network application, respectively. The SCL may perform the functions of the device service capability layer (DSCL), gateway service capability layer (GSCL), and network service capability layer (NSCL). That is, DA uses DSCL, GA uses GSCL, and NA uses NSCL.

The remote SCL may refer to the NSCL as the remote SCL when the SCL is DSCL. Alternatively, if the SCL is a GSCL, the NSCL may be referred to as a remote SCL. Alternatively, if the SCL is NSCL, DSCL or GSCL can be a remote SCL.

The remote SCL is applied when the DA and the DSCL or the GA and the GSCL constitute linkage information of the application ID and the SCL ID. That is, the remote SCL may be omitted when the NA and NSCL constitute linkage information of the application identification information and the service capability layer identification information.

This is because the remote SCL of NSCL can be DSCL or GSCL, because there are so many DSCL and GSCL that it is impossible to know which device's SCL to use. In addition, since most of the linkage information for collecting billing information is processed by the NSCL for the purpose of the invention, the NSCL does not need a remote SCL in most cases. However, if necessary, in the case of configuring the linkage information of the application identification information and the service capability layer identification information in the NA and NSCL, the method described later in the present invention may be similarly applied.

According to an embodiment of the present invention, after registering the SCL, a process as shown in FIG. 4 may be performed in the step of registering an application.

Referring to FIG. 4, the DA 400 generates an application (S410) and generates an application resource (S420). The DA 400 may be GA or NA, but is collectively referred to as DA for convenience of description below.

Subsequently, the DA 400 determines whether there is linkage information with the service capability layer identification information or the application identification information (S430). If there is linkage information with service capability layer identification information or application identification information, M2M service is provided to perform M2M communication.

However, if there is no linkage information with the service capability layer identification information or the application identification information, the DA 400 transmits an application creation request notification (ApplicationCreateRequestIndication) message to the SCL 500. In this case, the SCL 500 may be DSCL when the DA 400 is DA, GSCL when GA, and NSCL when NA.

On the other hand, the SCL 500 generates an SCL resource (S510) and then generates service capability layer identification information (SCL ID) (S520). When the SCL 500 receives the application generation request notification message from the DA 400, the SCL 500 checks the received message (S530) and transmits the received message to the remote SCL 600 if there is no error in the received message.

After generating the SCL resource (S610), the remote SCL 600 generates its service capability layer identification information (S620), and checks the received message when receiving the application generation request message from the SCL 500 (S630). ), If there is no error, creates an application resource and transmits an application creation request success (ApplicationCreateRequestConfirm) message (S640).

In addition, after generating the application resource, the remote SCL 600 stores the application identification information (appID) and service capability layer identification information (SCL ID) of the DA 400 and the SCL 500 in association with each other (S650). In this case, the application identification information and the service capability layer identification information may generate and store hash values, respectively. Such information may be stored as an attribute value of an application resource, for example, as shown in Table 4 below.

Subsequently, the remote SCL 600 transmits application identification information and service capability layer identification information or their hash values to the SCL 500, and the SCL 500 stores the transmitted information or hash values (S540) and the DA 400. Pass these information or hash values to the.

Therefore, the DA 400 may store the received application identification information and service capability layer identification information or their hash values in association.

After completing the above-described processes, the DA 400, the SCL 500, and the remote SCL 600 may perform M2M communication, respectively (S450, S550, S660). Can be collected using information and service capability layer identification information.

Hereinafter, the above-described process will be described taking an example in which an M2M device such as a scale registers an application. This example may be equally applicable to registering another application.

5 shows an example of an application resource according to an embodiment of the present invention.

In the case of registering the application DA for storing the weight measurement value in the service capability layer in the scale, the application resource may be generated as shown in FIG. 5.

Attribute information of the application resource is configured as shown in Table 4 below and stored in the scale.

On the other hand, when generating an application resource for the first time, there is no linkage information between the application identification information (Application ID) and the service capability layer identification information (SCL ID). However, when using an existing registered application resource, the linkage information may already be stored. .

Therefore, when the application resource is registered for the first time and there is no such linking information, the scale sends an application creation request notification (ApplicationCreateRequestIndication) message from the DA to the DSCL. DSCL checks for the presence of received application-generated request notification messages and, if there are no errors, the application resources as <DsclBase> / applications / <application> in <DsclBase> / scls / <scl> / where all resources in DSCL are stored. Register. If there is an error in the message, it responds to the DA with an application creation request failed (ApplicationCreateRequestConfirm failed) message.

AttributeName Mandatory / Optional Type Description expirationTime M RW See clause 9.2.2 Common attributes. This shall represent the expiration time of the registration. If the SCL does not refresh its registration before that time the resource is deleted and the application is de-registered. accessRightID O RW See clause 9.2.2 Common attributes. searchStrings M RW See clause 9.2.2 Common attributes. creationTime M RO See clause 9.2.2 Common attributes. lastModifiedTime M RO See clause 9.2.2 Common attributes. announceTo M RW See clause 9.2.2 Common attributes. aPoC O RW The Application Point of Contract is a URI that identifies how request are re-targeted. aPoCPaths O RW The aPocPaths, ifpresent, isusedtodetermineifatargetURIistobere-targeted , bydoingaprefixmatchagainsttheelementsinthepath.Eachpathcanoptionallyhavean accessRightID associatedwithit, which, ifpresent, isusedforauthorizationpurposeswhendoingthere-targeting.The accessRightID ofthebestmatchingpathprefixisusedforthispurpose.Thevalueof aPoCPaths isonlyrelevantwhenthe aPoC attributeisalsopresent. locRequestor O RW The identity of the Application to be used for the content of privacy control when requesting the location information of a remote M2M Device or Gateway.
This attribute is only used in the case that the location information is provided by a network-based location server (eg a 3GPP location server). It will be provided to the location server if the content is required for the location information retrieval.
The format of this attributed shall conform to the interface provided by the location server (eg MSISDN for a 3GPP location server). appId O WO An identifier for application that may have multiple appIdHash O WO Hash for appId sclId O WO An identifier for SCL that may have multiple sclIdHash O WO Hash for sclId

Table 4 shows attribute information of an application resource according to an embodiment of the present invention.

Attribute information can be configured as shown in Table 4 when generating an ApplicationCreateRequestIndication message sent or forwarded from the DA to DSCL or remote SCL and when an application resource <application> is created for each M2M object. have.

That is, the application resource <application> according to the preferred embodiment of the present invention may identify at least one of the application identification information (appId) and the hash value (appIdHash) attribute of the application identification information, the service capability layer identification information (sclId), and the service capability layer identification. By further including at least one of the information hash value (sclIdHash) attribute, it is possible to utilize the association information of the application identification information and the service providing capability identification information.

At this time, DSCL is identified as <DsclBase> / scls / <scl> /, and this can be used as service capability layer identification information (SCL ID). In addition, since DA is identified as <DsclBase> / applications / <application>, this can be used as application identification information (Application ID). That is, information of the application identification information (appId) <DsclBase> / applications / <application> and the service capability layer identification information (SCL ID) <DsclBase> / scls / <scl> / is shown as attribute information as shown in Table 4. You can manage the association information by storing it.

In addition, since the M2M device must communicate with the M2M server, the application resources must be registered in the NSCL. To this end, DSCL <DsclBase> / scls / <scl> / configures the information shown in Table 4 in the ApplicationCreateRequestIndication and sends it to the NSCL.

The NSCL checks for errors in the ApplicationCreateRequestIndication message received, and if there are no errors, the NSCL saves all resources in the NSCL. Stores application identification information and service capability layer identification information transmitted by DSCL as shown in Table 4 in / applications / <application>. On the other hand, if there is an error in the received message, it responds to DSCL with an application creation request failure message.

Meanwhile, the method for generating association information between application identification information (Application ID) and service capability layer identification information (SCL ID) in the NSCL is as follows.

<Example 1-1>

SCL ID: <NsclBase> / scls / <scl> /

Application ID: <NsclBase> / scls / <scl> / applications / <application>

<Example 2-1>

SCL ID: <DsclBase> / scls / <scl> /

Application ID: <DsclBase> / applications / <application>

The SCL ID is <NsclBase> / scls / <scl> / or <DsclBase> / scls / <scl> /. However, in some cases, <scl> is used as the ID. In this case, <scl> may overlap, so it is possible to use <NsclBase> / scls / <scl> /. To further reduce redundancy, it is also possible to use

<Example 1-2>

SCL ID: http://m2m.service.com/<NsclBase>/scls/<scl>/

Application ID: http://m2m.service.com/ <NsclBase> / scls / <scl> / applications / <application>

<Example 2-2>

SCL ID: http://m2m.device.com/<DsclBase>/scls/<scl>/

Application ID: http://m2m.device.com/ <DsclBase> / applications / <application>

On the other hand, for convenience of database construction and search efficiency, it may be more preferable to configure the identification information to have a constant length rather than a variable length. To this end, as described above, the association information may be configured by generating a hash value of the application identification information (Application ID) and the service capability layer identification information (SCL ID). This may be performed in the step of generating and storing the application identification information hash value and the service capability layer identification information hash value shown in FIG. 4.

6 is a flowchart illustrating a hash value generating method of application identification information and service capability layer identification information according to an exemplary embodiment of the present invention.

6, in order to generate a hash value of the application identification information and the service capability layer identification information according to the present invention, the length of the hash value is first determined. In the present invention, for example, the length of the hash value can be determined to be 8 characters or more. Characters used as hash values can be based on 62 lowercase letters (26), uppercase letters (26), and numbers (10). However, the hash value described here can be used based on other characters such as Hangul as well as changing the length of the hash value for the purpose of illustration only. Therefore, the above description and the following description of the length of the hash value or the type of character string used for the hash value do not limit the present invention.

When the application identification information or the service capability layer identification information as described above is input (S710), the SCL searches the database and checks whether a corresponding hash value exists in the existing operation (S720).

If there is no corresponding hash value in the database, SCL creates a new hash value. To this end, for example, when generating a seawater value with 8 digits, the reference value of 8 is compared with the repetition frequency (S730), and the character used for the hash value, for example, any one character from the above 62 characters is used. After selecting and storing (S740), the process of generating a string using the selected character (S750) is repeated eight times to generate a string.

Subsequently, the generated string is checked whether the same string exists, that is, whether it overlaps with the existing hash value (S760). If it is not duplicated, the generated string is stored and stored in the database for use as a hash value. S770).

However, if the hash value overlaps with the existing hash value, the process returns to step S730 to generate a new hash value.

On the other hand, if a hash value corresponding to the database exists as a result of the database search in step S720, the corresponding hash value found in the database is output and used (S780).

The following are examples of application identification information and service capability layer identification information generated according to the present invention.

<Example 1-3>

2SpBWRYO http://m2m.service.com/<NsclBase>/scls/<scl>/

QRAM4Eek http://m2m.service.com/ < NsclBase > / scls / < scl > / applications / < application >

<Example 2-3>

HyewAH2Z http://m2m.device.com/<DsclBase>/scls/<scl>/

NuvO2kBE http://m2m.device.com/ <DsclBase> / applications / <application>

Referring back to FIG. 4, the NCSL remote SCL 600 generates and stores an application ID hash value (appID hash) and a service capability layer ID hash value (SCl ID hash), as shown in Table 4 below. By configuring the attribute information of the application resource to generate an application creation request success (ApplicationCreateRequestConfirm) response message and transmits it to the SCL (500).

The following are examples of expressing application identification information (appId), application identification information hash value (appIdHash), service capability identification information (sclId), service capability identification information hash value (sclIdHash) in XML.

<Example 1-4>

<sclIdHash> 2SpBWRYO </ sclIdHash>

<sclId> http://m2m.service.com/ <NsclBase> / scls / <scl> / </ sclId>

<appIdHash> QRAM4Eek </ appIdHash>

<appId> http://m2m.service.com/ < NsclBase > / scls / < scl > / applications / < application > / </ appId >

<Example 2-4>

<sclIdHash> HyewAH2Z </ sclIdHash>

<sclId> http://m2m.device.com/ <DsclBase> / scls / <scl> / </ sclId>

<appIdHash> NuvO2kBE </ appIdHash>

<appId> http://m2m.device.com/ <DsclBase> / applications / <application> </ appId>

As described above, at least one of the 'appId' and 'appIdHash' attributes and at least one of the 'sclId' and 'sclIdHash' attributes are further added through a method of associating the application identification information with the service providing capability identification information according to the present invention. An apparatus for configuring an <application> resource, including, for example, a device or a gateway or a network server that provides an IoT communication service.

In addition, as described above, at least one of the 'appI' and 'appIdHash' attributes and at least one of the 'sclId' and 'sclIdHash' attributes may be further configured to configure an <application> resource to exchange and process ApplicationCreateRequestIndication and ApplicationCreateRequestIndication messages. A method and an apparatus, for example, a device or a gateway or a network server for providing a telecommunications service are provided.

In addition, a method for generating a hash value of an Application ID and an SCL ID by a device, a gateway, or a network server that provides an IoT communication service is provided.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited thereto. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

400: Application 500: SCL 600: Remote SCL

Claims (18)

In the M2M service providing method,
Receiving an application registration request from an M2M application at the M2M service capability layer; And
Registering the application by generating and storing an application resource including application identification information and service capability layer identification information in the service capability layer if there is no error in the received application registration request; M2M How we deliver the service.
The method of claim 1,
In the application registration step, M2M service providing method characterized in that for generating the application identification information hash value and service capability layer identification information hash value for the application identification information and the service capability layer identification information, respectively.
The method of claim 2,
In the application registration step, M2M service, characterized in that for storing at least one of the application identification information and the application identification information hash value and at least one of the service capability layer identification information and the service capability layer identification information hash value. How to Provide.
The method of claim 1,
The application identification information and the service capability layer identification information are stored as an attribute of the application resource M2M service providing method.
The method of claim 1,
Generating an application registration request response message including the application identification information and the service capability layer identification information in response to the application registration request in the service capability layer and transmitting the generated application registration request response message to the application; How to Provide M2M Services.
In the M2M platform,
Receiving an application registration request from the M2M application, if there is no error in the application registration request received, M2M to generate and store the application resource including the application identification information and service capability layer identification information to register the application. platform.
The method of claim 6,
And an application identification information hash value and a service capability layer identification hash value for the application identification information and the service capability layer identification information, respectively.
The method of claim 7, wherein
And at least one of the application identification information and the application identification information hash value and at least one of the service capability layer identification information and the service capability layer identification information hash value.
The method of claim 6,
M2M platform, characterized in that for storing the application identification information and the service capability layer identification information as an attribute of the application resource.
The method of claim 6,
M2M platform, characterized in that to generate an application registration request response message including the application identification information and the service capability layer identification information in response to the application registration request and to send to the application.
In the M2M service providing method,
Transmitting an application registration request from the M2M application to the M2M service capability layer; And
Storing the application identification information and the service capability layer identification information when the response message including the application identification information and the service capability layer identification information is received at the service capability layer in response to the application registration request. How to provide M2M service.
The method of claim 11,
If there is an application identification information hash value for the application identification information and the service capability layer identification information and a service capability layer identification information hash value in the response message, at least one of the application identification information and the application identification information hash value is stored. And storing at least one of the service capability layer identification information and the service capability layer identification information hash value.
The method of claim 11,
M2M service providing method, characterized in that the search for the application identification information and the service capability layer identification information exists in the M2M application and transmits the application registration request message if not.
The method of claim 11,
The application identification information and the service capability layer identification information are stored as an attribute of an application resource M2M service providing method.
In the M2M terminal,
The application registration request is transmitted to the M2M service capability layer, and upon receiving the response message including application identification information and service capability layer identification information at the service capability layer, the application identification information and the service capability layer identification are received. M2M terminal, characterized in that for storing information.
The method of claim 15,
If the application identification information and the application capability information hash value for the service capability layer identification information and the service capability layer identification information hash value exist in the response message, at least one of the application identification information and the application identification information hash value is stored. And at least one of the service capability layer identification information and the service capability layer identification information hash value.
The method of claim 15,
The M2M terminal detects whether the application identification information and the service capability layer identification information exist in the M2M terminal and transmits the application registration request message if the application identification information does not exist.
The method of claim 15,
M2M terminal, characterized in that for storing the application identification information and the service capability layer identification information as an attribute of an application resource.

Images