Method and apparatus for identifying service entity in machine to machine system

Abstract

The present invention relates to a method and apparatus for identifying a service entity in a Machine-to-Machine (M2M) system. A method for an M2M device to request a service comprises the steps of: transmitting a message to a registry inquiring about information regarding a service entity; obtaining information related to said service entity; and using said service entity to utilize the service.

Description

Technology Field

[0001] The present invention relates to a method and apparatus for identifying a service entity in a Machine-to-Machine (M2M) system. More specifically, the present invention relates to a method and apparatus for identifying a service entity that provides a service suitable for an application in an M2M system. Background Technology

[0002] Recently, the adoption of M2M (Machine-to-Machine) systems has been increasing rapidly. M2M communication can refer to communication performed between machines without human intervention. M2M can refer to MTC (Machine Type Communication), IoT (Internet of Things), or D2D (Device-to-Device). However, for the convenience of explanation, the term M2M will be used consistently below, but it is not limited to this. The terminal used for M2M communication may be an M2M terminal (M2M device). An M2M terminal is generally a device with low mobility that transmits small amounts of data. In this case, the M2M terminal can be used in conjunction with an M2M server that centrally stores and manages communication information between machines.

[0003] In addition, M2M terminals can be applied in various systems, such as object tracking, vehicle integration, and power metering.

[0004] Meanwhile, regarding M2M terminals, the oneM2M standardization organization provides technical specifications for requirements, architecture, API (Application Program Interface) specifications, security solutions, and interoperability for M2M communication, IoT, and IoT technologies. The specifications of the oneM2M standardization organization provide a framework that supports various applications and services, such as smart cities, smart grids, connected cars, home automation, public safety, and health. The problem to be solved

[0005] The present invention aims to provide a method and apparatus for identifying a service entity capable of providing appropriate services in a Machine-to-Machine (M2M) system. means of solving the problem

[0006] According to one embodiment of the present invention, a method for an M2M device to request a service in a Machine-to-Machine (M2M) system comprises the steps of: transmitting a message to a registry inquiring about information regarding a service entity; obtaining information related to the service entity; and using the service entity to request a service.

[0007] According to one embodiment of the present invention, a method for an M2M device to provide a service in an M2M system comprises the steps of: transmitting a first message requesting a registry to register information about the M2M device; receiving a second message from the registry confirming the completion of the registration; receiving a third message requesting a service from another M2M device based on information about the M2M device registered in the registry; and providing a service to the other M2M device.

[0008] According to one embodiment of the present invention, a method for an M2M device operating as a registry in an M2M system to provide information about a service entity comprises the steps of: receiving a first message requesting the registration of information about the service entity from the service entity; transmitting a second message confirming the completion of the registration; receiving a third message requesting information about the service entity from another M2M device; and transmitting information about the service entity to the other M2M device.

[0009] According to one embodiment of the present invention, a device requesting a service in an M2M system includes a transceiver that transmits and receives signals and a processor that controls the transceiver. The processor transmits a message inquiring about information regarding a service entity to a registry, obtains information related to the service entity, and uses the service entity to utilize the service.

[0010] According to one embodiment of the present invention, a device providing a service in an M2M system includes a transceiver that transmits and receives signals and a processor that controls the transceiver. The processor transmits a first message requesting a registry to register information about the M2M device, receives a second message confirming the completion of the registration from the registry, receives a third message requesting a service from another M2M device based on information about the M2M device registered in the registry, and provides a service to the other M2M device.

[0011] According to one embodiment of the present invention, a device that operates as a registry in an M2M system and provides information about a service entity includes a transceiver that transmits and receives signals and a processor that controls the transceiver. It receives a first message requesting the registration of information about the service entity from the service entity, transmits a second message confirming the completion of the registration, receives a third message requesting information about the service entity from another M2M device, and transmits information about the service entity to the other M2M device. Effects of the invention

[0012] According to the present disclosure, information regarding a Common Service Entity (CSE) capable of providing appropriate Internet of Things (IoT) services to be used by an Application Entity (AE) can be effectively provided.

[0013] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below. Brief explanation of the drawing

[0014] FIG. 1 is a diagram showing the hierarchical structure of a Machine-to-Machine (M2M) system according to the present disclosure. FIG. 2 is a diagram showing a reference point in an M2M system according to the present disclosure. FIG. 3 is a diagram showing each node in an M2M system according to the present disclosure. FIG. 4 is a diagram showing common service functions in an M2M system according to the present disclosure. FIG. 5 is a diagram illustrating a method in which a sender and a receiver exchange messages in an M2M system according to the present disclosure. FIG. 6 is a diagram illustrating an example of interaction between oneM2M entities in an M2M system according to the present disclosure. FIG. 7 is a diagram illustrating an example of a procedure for the registration and discovery of a CSE in an M2M system according to the present disclosure. FIG. 8 is an M2M system according to the present disclosure <platformregistry>This is a diagram showing an example of a procedure for adding a description of a platform using [it]. FIG. 9 is a diagram illustrating the operation method of a device requesting a service in an M2M system according to the present disclosure. FIG. 10 is a diagram illustrating the operation method of a device providing services in an M2M system according to the present disclosure. FIG. 11 is a diagram illustrating the operation method of a device that provides information about a device providing a service in an M2M system according to the present disclosure. FIG. 12 is a diagram showing the configuration of an M2M device in an M2M system according to the present disclosure. Specific details for implementing the invention

[0015] Hereinafter, embodiments of the present disclosure are described in detail with reference to the attached drawings so that those skilled in the art can easily implement them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein.

[0016] In the present disclosure, terms such as first, second, etc. are used solely for the purpose of distinguishing one component from another component and do not limit the order or importance of the components unless specifically stated otherwise. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and likewise, a second component in one embodiment may be referred to as a first component in another embodiment.

[0017] In the present disclosure, when a component is described as being "connected," "combined," or "joined" with another component, this may include not only a direct connection but also an indirect connection in which another component exists in between. Furthermore, when a component is described as "comprising" or "having" another component, this means that, unless specifically stated otherwise, it does not exclude the other component but may include an additional component.

[0018] In this disclosure, distinct components are intended to clearly describe their respective features and do not imply that the components are separate. That is, multiple components may be integrated to form a single hardware or software unit, or a single component may be distributed to form multiple hardware or software units. Accordingly, such integrated or distributed embodiments are included within the scope of this disclosure, even if not otherwise mentioned.

[0019] In the present disclosure, the components described in various embodiments are not necessarily essential components, and some may be optional components. Accordingly, embodiments consisting of a subset of the components described in one embodiment are also included within the scope of the present disclosure. Furthermore, embodiments including additional components in addition to the components described in various embodiments are also included within the scope of the present disclosure.

[0020] In describing the embodiments of the present disclosure, if it is determined that a detailed description of known configurations or functions could obscure the essence of the present disclosure, such detailed description is omitted. Additionally, parts of the drawings unrelated to the description of the present disclosure have been omitted, and similar parts are denoted by similar reference numerals.

[0021] In addition, this specification describes a network based on M2M (Machine-to-Machine) communication, and operations performed in an M2M communication network may be carried out in the process of controlling the network and transmitting data by a system governing the communication network.

[0022] Furthermore, in this specification, an M2M terminal may be a terminal that performs M2M communication, but may also be a terminal that operates in a wireless communication system with backward compatibility in mind. That is, an M2M terminal may refer to a terminal that can operate based on an M2M communication network, but is not limited to an M2M communication network. An M2M terminal may also be capable of operating based on other wireless communication networks and is not limited to the embodiments described above.

[0023] In addition, M2M terminals can be fixed or mobile. Furthermore, an M2M server refers to a server for M2M communication and can be a fixed station or a mobile station.

[0024] Additionally, in this specification, an entity may refer to hardware such as an M2M device, an M2M gateway, or an M2M server. Furthermore, as an example, an entity may be used to refer to a software configuration in the hierarchical structure of an M2M system, and is not limited to the embodiments described above.

[0025] In addition, as an example, the present invention is described with reference to an M2M system, but the present invention is not limited to an M2M system.

[0026] Additionally, the M2M server may be a server that communicates with an M2M terminal or another M2M server. Furthermore, the M2M gateway may serve as a connection point connecting the M2M terminal and the M2M server. For example, if the networks of the M2M terminal and the M2M server are different, they may be connected to each other through the M2M gateway. In this case, for example, both the M2M gateway and the M2M server may be M2M terminals, but are not limited to the embodiments described above.

[0028] oneM2M is a de facto standardization organization established to develop a common IoT service platform that integrates and shares application service infrastructure (platform) environments, moving away from fragmented service platform development structures that operate in a dependent and closed manner by industry, such as energy, transportation, defense, and public services. oneM2M aims to provide requirements, architecture, API (Application Program Interface) specifications, security solutions, and interoperability for IoT and IoT technologies. For example, oneM2M specifications provide a framework that supports various applications and services, such as smart cities, smart grids, connected cars, home automation, public safety, and health. To this end, oneM2M has developed a set of standards that defines a single horizontal platform for the exchange and sharing of data among all applications. The applications considered by oneM2M may include those spanning different industrial sectors. By providing a framework for interoperability with different technologies—much like an operating system—oneM2M is creating a distributed software layer that promotes unification. The distributed software layer is implemented in a common service layer located between the communication hardware / software that provides data transmission and M2M applications. For example, the common service layer may occupy part of a layered structure such as Figure 1.

[0030] FIG. 1 is a diagram showing the layered structure of a Machine-to-Machine (M2M) system according to the present disclosure.

[0031] Referring to FIG. 1, the layered structure of the M2M system may consist of an application layer (110), a common service layer (120), and a network service layer (120). In this case, the application layer (110) may be a layer that operates based on a specific application. For example, the application may be a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application. That is, the application layer may be a layer for a specific application. In this case, the entity that operates based on the application layer may be an Application Entity (AE).

[0032] The common service layer (120) may be a layer for a common service function (CSF). For example, the common service layer (120) may be a layer for providing common services such as data management, device management, M2M service subscription management, location services, etc. For example, an entity operating based on the common service layer (120) may be a common service entity (CSE).

[0033] The common service layer (120) may provide a set of services that are grouped into CSFs by function. A number of instantiated CSFs form CSEs. CSEs may interface with applications (e.g., application entities or AEs in oneM2M nomenclature), other CSEs, and underlying networks (e.g., network service entities or NSEs in oneM2M nomenclature).

[0034] The network service layer (120) can provide services such as device management, location service, and device triggering to the common service layer (120). At this time, the entity operating based on the network layer (120) may be a network service entity (NSE).

[0036] FIG. 2 is a diagram showing a reference point in an M2M system according to the present disclosure.

[0037] Referring to FIG. 2, the M2M system structure can be distinguished into a Field Domain and an Infrastructure Domain. In this case, each entity in each domain can communicate through a reference point (e.g., Mca or Mcc). For example, a reference point can represent the communication flow between each entity. In this case, referring to FIG. 2, an Mca reference point, which is a reference point between AE (210 or 240) and CSE (220 or 250), an Mcc reference point, which is a reference point between different CSEs, and a Mcn reference point, which is a reference point between CSE (220 or 250) and NSE (230 or 260), can be established.

[0039] FIG. 3 is a diagram showing each node in an M2M system according to the present disclosure.

[0040] Referring to FIG. 3, the infrastructure domain of a specific M2M service provider may provide a specific infrastructure node (310, Infrastructure Node, IN). In this case, the CSE of the IN may communicate with the AE of another infrastructure node based on the Mca reference point. In this case, one IN may be configured for each M2M service provider. That is, the IN may be a node that communicates with an M2M terminal of another infrastructure based on the infrastructure structure. Additionally, as an example, the concept of a node may be a logical entity or a software configuration.

[0041] Next, the Application Dedicated Node (320, ADN) may be a node that includes at least one AE and does not include a CSE. In this case, the ADN may be configured in a field domain. That is, the ADN may be a node dedicated to the AE. For example, the ADN may be a node configured in hardware on an M2M terminal. Additionally, the Application Service Node (330, ASN) may be a node that includes one CSE and at least one AE. The ASN may be configured in a field domain. That is, it may be a node that includes an AE and a CSE. In this case, the ASN may be a node connected to an IN. For example, the ASN may be a node configured in hardware on an M2M terminal.

[0042] Additionally, the middle node (340, Middle Node, MN) may be a node that includes a CSE and zero or more AEs. In this case, the MN may be configured in a field domain. The MN may be connected to other MNs or INs based on a reference point. Also, as an example, the MN may be configured in hardware on an M2M gateway.

[0043] In addition, as an example, a non-M2M device node (350, Non-M2M device node, NoDN) is a node that does not contain M2M entities and may be a node that performs management or collaboration with an M2M system.

[0045] FIG. 4 is a diagram showing common service functions in an M2M system according to the present disclosure.

[0046] Referring to FIG. 4, common service functions may be provided. For example, a common service entity may provide at least one of the following CSFs: Application and Service Layer Management (402), Communication Management and Delivery Handling (404), Data Management and Repository (406), Device Management (408), Discovery (410), Group Management (412), Location (414), Network Service Exposure / Service Execution and Triggering (416), Registration (418), Security (420), Service Charging and Accounting (422), Service Session Management, and Subscription / Notification (424). At this time, M2M terminals may operate based on the common service functions. In addition, the common service function may have other embodiments and is not limited to the embodiments described above.

[0047] Application and Service Layer Management (402) CSF provides management of AEs and CSEs. Application and Service Layer Management (402) CSF includes the ability to configure, troubleshoot, and upgrade the functions of CSEs, as well as upgrade AEs.

[0048] The communication management and forwarding processing (404) CSF provides communications with other CSEs, AEs, and NSEs. The communication management and forwarding processing (404) CSF determines when and to which communication connection to forward communications and decides to buffer communication requests so that they can be forwarded later if necessary and permissible.

[0049] Data Management and Storage (406) CSF provides data storage and mediation functions (e.g., data collection for aggregation, data reformatting, and data storage for analysis and semantic processing).

[0050] Device management (408) CSF provides management of device capabilities on M2M gateways and M2M devices.

[0051] Discovery (410) CSF provides a function to search for information about applications and services based on filter criteria.

[0052] The group management (412) CSF provides processing of group-related requests. The group management (412) CSF enables the M2M system to support bulk operations on multiple devices, applications, etc.

[0053] Location (414) CSF provides a function that enables AEs to obtain geographical location information.

[0054] Network service exposure / service execution and triggering (416) CSF manages communications with underlying networks to access network service functions.

[0055] Registration (418) CSF provides a function for AEs (or other remote CSEs) to register with the CSE. Registration (418) CSF allows AEs (or remote CSEs) to use the services of the CSE.

[0056] Security (420) CSF provides security functions for service layers such as access control including identification, authentication, and authorization.

[0057] Service billing and calculation (422) CSF provides billing functions for the service layer.

[0058] Subscription / Notification (424) CSF allows subscription to events and provides a function to be notified when the event occurs.

[0060] FIG. 5 is a diagram illustrating a method in which a sender and a receiver exchange messages in an M2M system according to the present disclosure.

[0061] Referring to FIG. 5, the sender (originator, 510) can transmit a request message to the receiver (receiver, 520). At this time, the sender (510) and the receiver (520) may be the M2M terminals described above. However, they are not limited to M2M terminals, and the sender (510) and the receiver (520) may be other terminals and are not limited to the embodiments described above. Additionally, as an example, the sender (510) and the receiver (520) may be the nodes, entities, servers, or gateways described above. That is, the sender (510) and the receiver (520) may be hardware or software configurations and are not limited to the embodiments described above.

[0062] In this case, for example, the request message transmitted by the sender (510) may include at least one parameter. In this case, for example, the parameter may be a mandatory parameter or an optional parameter. For example, parameters related to the sending end, parameters related to the receiving end, identification parameters, and operation parameters may be mandatory parameters. Additionally, other information may be optional parameters. In this case, the parameters related to the sending end may be parameters for the sender (510). Additionally, the parameters related to the receiving end may be parameters for the receiver (520). Additionally, the identification parameters may be parameters required for mutual identification.

[0063] Additionally, the action parameter may be a parameter for distinguishing actions. For example, the action parameter may be set to at least one of Create, Retrieve, Update, Delete, and Notify. In other words, it may be a parameter for distinguishing actions.

[0064] At this time, when the receiver (520) receives a request message from the sender (510), it can process the request message. For example, the receiver (520) can perform an action included in the request message, and to do so, it can determine whether the parameters are valid and whether there is permission. At this time, if the parameters are valid and there is permission, the receiver (520) can check whether the resource to be requested exists and perform processing based on this.

[0065] For example, when an event occurs, the sender (510) may send a request message containing parameters for a notification to the receiver (520). The receiver (520) may check the parameters for the notification included in the request message, perform an action based thereon, and send a response message back to the sender (510).

[0066] A message exchange procedure using request and response messages as shown in FIG. 5 can be performed between an AE and a CSE based on an Mca reference point or between CSEs based on an Mcc reference point. That is, the sender (510) may be an AE or a CSE, and the receiver (520) may be an AE or a CSE. Depending on the operation within the request message, a message exchange procedure as shown in FIG. 5 may be initiated by an AE or a CSE.

[0068] Requests from a requester to a receiver through reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. That is, each defined parameter may be mandatory or optional depending on the requested operation. For example, a response message may include at least one of the parameters listed in below.

[0069] Response message parameter / success or not Response Status Code - successful, unsuccessful, ack Request Identifier - uniquely identifies a Request message Content - to be transferred To - the identifier of the Originator or the Transit CSE that sent the corresponding non-blocking request From - the identifier of the Receiver Originating Timestamp - when the message was built Result Expiration Timestamp - when the message expires Event Category - what event category shall be used for the response message Content Status Content Offset Token Request Information Assigned Token Identifiers Authorization Signature Request Information Release Version Indicator - the oneM2M release version that this response message conforms to

[0070] Filter criteria conditions that can be used in request messages or response messages can be defined as shown in and below.

[0071] Condition tag Multip-licity Description Matching Conditions createdBefore 0..1 The creationTime attribute of the matched resource is chronologically before the specified value. createdAfter 0..1 The creationTime attribute of the matched resource is chronologically after the specified value. modifiedSince 0..1 The lastModifiedTime attribute of the matched resource is chronologically after the specified value. unmodifiedSince 0..1 The lastModifiedTime attribute of the matched resource is chronologically before the specified value. stateTagSmaller 0..1 The stateTag attribute of the matched resource is smaller than the specified value. stateTagBigger 0..1 The stateTag attribute of the matched resource is bigger than the specified value. expireBefore 0..1 The expirationTime attribute of the matched resource is chronologically before the specified value. expireAfter 0..1 The expirationTime attribute of the matched resource is chronologically after the specified value. labels 0..1 The labels attribute of the matched resource matches the specified value. labelsQuery 0..1 The value is an expression for the filtering of labels attribute of resource when it is of key-value pair format. The expression is about the relationship between label-key and label-value which may include equal to or not equal to, within or not within a specified set etc. For example, label-key equals to label value, or label-key within {label-value1, label-value2}. Details are defined in [3] childLabels 0..1 A child of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3]. parentLabels 0..1 The parent of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3]. resourceType 0..n The resourceType attribute of the matched resource is the same as the specified value. It also allows differentiating between normal and announced resources. childResourceType 0..n A child of the matched resource has the resourceType attribute the same as the specified value. parentResourceType 0..1 The parent of the matched resource has the resourceType attribute the same as the specified value. sizeAbove 0..1 The contentSize attribute of the <contentinstance> matched resource is equal to or greater than the specified value. < / contentinstance> sizeBelow 0..1 The contentSize attribute of the <contentinstance> matched resource is smaller than the specified value. < / contentinstance> contentType 0..n The contentInfo attribute of the <contentinstance> matched resource matches the specified value. < / contentinstance> attribute 0..n This is an attribute of resource types (clause 9.6). Therefore, a real tag name is variable and depends on its usage and the value of the attribute can have wild card *. E.g. creator of container resource type can be used as a filter criteria tag as "creator=Sam", "creator=Sam*", "creator=*Sam". childAttribute 0..n A child of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above. parentAttribute 0..n The parent of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above. semanticsFilter 0..n Both semantic resource discovery and semantic query use semanticsFilter to specify a query statement that shall be specified in the SPARQL query language [5]. When a CSE receives a RETRIEVE request including a semanticsFilter, and the Semantic Query Indicator parameter is also present in the request, the request shall be processed as a semantic query; otherwise, the request shall be processed as a semantic resource discovery. In the case of semantic resource discovery targeting a specific resource, if the semantic description contained in the <semanticdescriptor> of a child resource matches the semanticFilter, the URI of this child resource will be included in the semantic resource discovery result. In the case of semantic query, given a received semantic query request and its query scope, the SPARQL query statement shall be executed over aggregated semantic information collected from the semantic resource(s) in the query scope and the produced output will be the result of this semantic query. Examples for matching semantic filters in SPARQL to semantic descriptions can be found in [i.28]. < / semanticdescriptor> filterOperation 0..1 Indicates the logical operation (AND / OR) to be used for different condition tags. The default value is logical AND. contentFilterSyntax 0..1 Indicates the Identifier for syntax to be applied for content-based discovery. contentFilterQuery 0..1 The query string shall be specified when contentFilterSyntax parameter is present.

[0072] Condition tag Multip-licity Description Filter Handling Conditions filterUsage 0..1 Indicates how the filter criteria is used. If provided, possible values are 'discovery' and 'IPEOnDemandDiscovery'.If this parameter is not provided, the Retrieve operation is a generic retrieve operation and the content of the child resources fitting the filter criteria is returned.If filterUsage is 'discovery', the Retrieve operation is for resource discovery (clause 10.2.6), i.e. only the addresses of the child resources are returned.If filterUsage is 'IPEOnDemandDiscovery', the other filter conditions are sent to the IPE as well as the discovery Originator ID. When the IPE successfully generates new resources matching with the conditions, then the resource address(es) shall be returned. This value shall only be valid for the Retrieve request targeting an <ae> resource that represents the IPE. < / ae> limit 0..1 The maximum number of resources to be included in the filtering result. This may be modified by the Hosting CSE. When it is modified, then the new value shall be smaller than the suggested value by the Originator. level 0..1 The maximum level of resource tree that the Hosting CSE shall perform the operation starting from the target resource (i.e. To parameter). This shall only be applied for Retrieve operation. The level of the target resource itself is zero and the level of the direct children of the target is one. offset 0..1 The number of direct child and descendant resources that a Hosting CSE shall skip over and not include within a Retrieve response when processing a Retrieve request to a targeted resource. applyRelativePath 0..1 This attribute contains a resource tree relative path (e.g. .. / tempContainer / LATEST). This condition applies after all the matching conditions have been used (i.e. a matching result has been obtained). The attribute determines the set of resource(s) in the final filtering result. The filtering result is computed by appending the relative path to the path(s) in the matching result. All resources whose Resource-IDs match that combined path(s) shall be returned in the filtering result. If the relative path does not represent a valid resource, the outcome is the same as if no match was found, i.e. there is no corresponding entry in the filtering result.

[0073] A response to a request for accessing resources through reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. That is, each defined parameter may be mandatory or optional depending on the requested operation or mandatory response code. For example, a request message may include at least one of the parameters listed in below.

[0074] Request message parameter Mandatory Operation - operation to be executed / CREAT, Retrieve, Update, Delete, Notify To - the address of the target resource on the target CSE From - the identifier of the message Originator Request Identifier - uniquely identifies a Request message Operation dependent Content - to be transferred Resource Type - of resource to be created Optional Originating Timestamp - when the message was built Request Expiration Timestamp - when the request message expires Result Expiration Timestamp - when the result message expires Operational Execution Time - the time when the specified operation is to be executed by the target CSE Response Type - type of response that shall be sent to the Originator Result Persistence - the duration for which the reference containing the responses is to persist Result Content - the expected components of the result Event Category - indicates how and when the system should deliver the message Delivery Aggregation - aggregation of requests to the same target CSE is to be used Group Request Identifier - Identifier added to the group request that is to be fanned out to each member of the group Group Request Target Members-indicates subset of members of a group Filter Criteria - conditions for filtered retrieve operation Desired Identifier Result Type - format of resource identifiers returned Token Request Indicator - indicating that the Originator may attempt Token Request procedure (for Dynamic Authorization) if initiated by the Receiver Tokens - for use in dynamic authorization Token IDs - for use in dynamic authorization Role IDs - for use in role based access control Local Token IDs - for use in dynamic authorization Authorization Signature Indicator - for use in Authorization Relationship Mapping Authorization Signature - for use in Authorization Relationship Mapping Authorization Relationship Indicator - for use in Authorization Relationship Mapping Semantic Query Indicator - for use in semantic queries Release Version Indicator - the oneM2M release version that this request message conforms to. Vendor Information

[0075] A normal resource includes a complete set of representations of data that constitute the base of the information to be managed. Unless virtual or announced, resource types in this document may be understood as normal resources.

[0076] Virtual resources are used to trigger processing and / or retrieval results. However, virtual resources do not have a permanent representation within CSE.

[0077] An announced resource contains a set of attributes of the original resource. When the original resource changes, the announced resource is automatically updated by the original resource's hosting CSE. The announced resource contains a link to the original resource.

[0078] Resource announcement enables resource discovery. A declared resource in a remote CSE can be used to create child resources in the remote CSE that are not present as children of the original resource or are not declared children.

[0079] To support the declaration of resources, additional columns within the resource template can specify the attributes to be declared for inclusion within the related declared resource type. Each declared <resourcetype>Regarding, original <resourcetype>The addition of the suffix 'Annc' to can be used to indicate the related declared resource type. For example, resource <containerannc>Is <container>You can specify the declared resource type for the resource, and <groupannc>Is <group>It can indicate the declared resource type for.

[0081] An environment may exist where a large number of Infrastructure Node (IN)-CSEs exist in a specific region (e.g., cities, smart cities), and these IN-CSEs provide various IoT services through diverse IoT service providers. In this case, various problematic situations may arise from the perspective of an IoT device entering that region. For instance, these issues may include how an IoT application running on a device can locate the desired IN-CSE among the numerous IoT service platforms, whether the application needs to identify the provider offering the desired service, whether the user can discover available IN-CSEs for the service they want (e.g., smart parking), whether the application can identify the IN-CSEs providing a specific service, and how many oneM2M IoT service platforms are currently in operation.

[0083] FIG. 6 is a diagram illustrating an example of interaction between oneM2M entities in an M2M system according to the present disclosure.

[0084] Referring to FIG. 6, at step S601, the oneM2M service provider (620) sends a registration request for service description to the service registry (630). At step S603, the oneM2M service requestor (610) sends a query for available services to the service registry (630). For example, the query may be a query for IN-CSE. At step S605, the service registry (630) sends discovery results to the oneM2M service requestor (610). At this time, the discovery results may be provided along with status information.

[0085] In step S607, the oneM2M service requester (610) sends a request for the selected IN-CSE to the service registry (630). In step S609, the service registry (630) sends service information for the selected IN-CSE to the oneM2M service requester (610). In step S611, the service registry (630) performs an availability check on the oneM2M service provider (620).

[0087] The procedure described with reference to Fig. 6 includes the registration, discovery, and management of oneM2M service platforms. To discover oneM2M service platforms, a service platform registry is required. This requires describing and registering oneM2M service layer platforms (e.g., IN-CSE). The publication of IN-CSE requires a proper description of the hosting IoT service in terms of business, service, and technical information. Registration handles the operation of persistently storing the IN-CSE description within the IoT service platform registry.

[0089] Service platform discovery is the process of locating IoT service providers and searching for already published IoT service provider descriptions.

[0090] The interrogating service involves querying a service registry for IoT service platforms that meet the requirements of the service platform requester. The query includes search criteria such as the type of desired service, preferred price, and the maximum number of results to be returned. The query is executed against service information issued by service providers. The discovery of an IoT service platform is a process dependent on the structure of the service registry. Once the discovery process is complete, the IoT application can determine the exact location of the in-CSE via the Contact of Address (CoA) and how to interface with the in-CSE.

[0091] In the procedure of FIG. 6, the availability check is an operation for monitoring the availability of use of a registered service and may be referred to as a liveness check. The registry may periodically check the liveness of at least one IN-CSE. An IN-CSE may not be available due to various factors. For example, factors may include at least one of maintenance, out of order, or temporary disorder. An unavailable IN-CSE may not be found or may be found in an unavailable status.

[0093] FIG. 7 is a diagram illustrating an example of a procedure for the registration and discovery of a CSE in an M2M system according to the present disclosure. FIG. 7 is an example of a procedure in which an IN-CSE-1 (720) existing in a specific area registers with a registry (730), and an ADN-AE (710) that has entered the area uses the services provided by the IN-CSE-1 (720).

[0094] Referring to FIG. 7, at step S701, IN-CSE-1 (720) sends a request to register to the registry (730). At step S703, the registry (730) registers IN-CSE. At step S705, the registry (730) sends a response for the registration to IN-CSE-1 (720). At step S707, the registry (730) and IN-CSE-1 (720) perform a liveness check and acknowledgment. That is, the registry (730) sends a message for a liveness check to IN-CSE-1 (720), and IN-CSE-1 (720) sends a message for an acknowledgment (ACK) to the registry (730).

[0095] In step S709, ADN-AE (710) visits an area operated by IN-CSE-1 (720). In step S711, ADN-AE (710) sends a query for available IN-CSEs or specific IN-CSEs providing a specific service to the registry (730). Here, the available IN-CSEs may be at least one available IN-CSE in the visited area. For example, the specific service may be a V2X (vehicle to everything) service.

[0096] In step S713, the registry (730) sends a return available IN CSEs to the ADN-AE (710). In other words, the registry (730) provides the ADN-AE (710) with information about the available IN CSEs (e.g., list, available services, etc.).

[0097] In step S715, ADN-AE (710) sends a request for information required to get an access to IN-CSE-1 (720) to the registry (730). In other words, if necessary, ADN-AE (710) requests information required to get an access to IN-CSE-1 (720) from the registry (730). In step S717, ADN-AE (710) uses IN-CSE-1 (720). In other words, ADN-AE (710) uses IN-CSE-1 (720) to receive the corresponding service.

[0099] As explained with reference to FIG. 7, IN-CSE-1 (720) and the registry (730) communicate for registration, and ADN-AE (710) and the registry (730) communicate for discovery. At this time, the protocol and requirements used for communication between entities are described in more detail as follows.

[0100] The IN-CSE and the registry may use the HTTP protocol to exchange IN-CSE descriptions. The IN-CSE description may be stored as XML-based service characters. For example, the IN-CSE description may include at least one of a CoA (e.g., IP address), port number, name of IN-CSE, status, profile of IN-CSE, type of IN-CSE, supported public services, maintenance information (e.g., maintenance time 01:00 ~ 02:00), access information, or credential.

[0101] Universal description, discovery, and integration can be used to describe IN-CSE. A oneM2M specific XML format can be defined to include IN-CSE information.

[0102] The oneM2M system can enable M2M applications to discover available M2M services and M2M infrastructure through the oneM2M repository. The oneM2M system can enable M2M infrastructure nodes to notify the oneM2M repository of availability.

[0104] As described above, a CSE can register its information in a registry. A CSE that wishes to be registered in a registry registers its information with a CSE acting as the registry; however, this procedure is not initiated by the CSE itself but by an AE. That is, the AE sends a message to the CSE instructing it to provide the CSE's information to another CSE acting as the repository. Since the CSE has received information from the other CSE acting as the repository from the AE, it creates a message using the information provided by the AE and the information it possesses, and transmits the message to a target CSE, that is, a CSE acting as the repository.

[0105] To this end, according to one embodiment of the present invention, resources <platformregistry>...can be used. Specifically, the CSE wishing to register [it] to another CSE acting as the registry <platformregistry>Requests to add information to the resource, and another CSE acting as a repository manages the received information. <platformregistry>Can be added to resources. <platformregistry>The procedure for utilizing resources is detailed as follows.

[0107] FIG. 8 is an M2M system according to the present disclosure <platformregistry>This is a diagram showing an example of a procedure for adding a description of a platform using [it].

[0108] Referring to FIG. 8, in step S801, the AE (810) requests the local CSE (820) to publish the platform to the target CSE. In other words, the AE (810) initiates the publication of the platform to the target CSE.

[0109] In step S803, the local CSE (820) performs local processing. Specifically, the local CSE generates a request message to add information about its platform description to the target CSE. The request message may include at least one of a point of contact, an access token, a supporting service, and a supporting oneM2M feature (e.g., edge, multicast, etc.).

[0110] In step S805, the local CSE (820) tells the remote CSE (830) <platformregistry>A request is made to add a new platform description record to the resource. That is, the local CSE (820) sends the request message generated in step S803 to the remote CSE (830), which is the target CSE.

[0111] In step S807, the remote CSE (830) performs local processing. In other words, the remote CSE (830) uses the platform description information of the local CSE (820). <platformregistry>Add to. Then, at step S809, the remote CSE (830) sends a response to the local CSE (820). At step S811, the local CSE (820) sends a response to the AE (810).

[0112] <platformregistry>The relevant reference points for the initiation of the action of adding a record to are Mca, Mcc, and Mcc'. The initial request is an indication of publishing a platform description, the address of the target CSE (e.g., <platformregistry>Location of CSE hosting resources <platformregistry>It may include at least one of the resources.

[0113] Additionally, the target CSE may be the originator of the initiation. In other words, in the procedure of FIG. 8, the AE (810) and the remote CSE (830) may be the same entity. Or, in the procedure of FIG. 8, the local CSE (820) and the remote CSE (830) may be the same entity.

[0114] <platformregistry>The structure of is as follows. <platformregistry>Resources are used to store platform descriptions of various available oneM2M platforms that are publicly open to business relationships or anyone. <platformregistry>Information from can be used by the application or CSE to find platforms that provide specific services or nearby available platforms.

[0115] for example, <platformregistry>Resources may include attributes such as those shown in below.

[0116] addressOfPlatform, 0..1 (L), address of platformaccessToken, 0..1 (L), access token to be used to access to the described platformserviceLabel, 0..1 (L), available services in the platformfeatureLable, 0..1 (L), supporting features from the platformLocation, 0..1 (L), location of the platform (this information can be a GPS value or country or city)

[0117] According to another embodiment, <platformregistry>The resource may include the attributes listed in above and other attributes. According to one embodiment, <platformregistry>Resources can be added as child resources of other resources. For example, other resources are <csebase>or <remotecse>It could be.

[0119] FIG. 9 is a diagram illustrating the operation method of a device requesting a service in an M2M system according to the present disclosure. The operating entity of FIG. 9 may be the AE of the device requesting the service. In the following description, the operating entity of the procedure of FIG. 9 is referred to as the 'device'.

[0120] Referring to FIG. 9, in step S901, the device transmits a query message for a service entity to the registry. The query message may include information regarding search criteria for identifying the service entity to be verified in the device's AE. Depending on the search criteria, the query message may be understood as a query for a service entity (e.g., CSE), a query for a service, or a query for a region. For example, the search criteria may be related to at least one of the device, service, service entity, or search result. Specifically, the search criteria may be at least one of the device's location, a specific service, a category of a specific service, all available services, or available service entities.

[0121] In step S903, the device receives information about a service entity. That is, as a response to an inquiry message, the device receives identification information about at least one service entity identified according to search criteria from a registry. The identification information about the service entity may include a list containing at least one service entity. Here, the at least one service entity included in the list is a service entity registered in the registry. According to one embodiment, the information about the service entity may further include at least one of information about the status of the at least one service entity and information about a service that can be provided by the at least one service entity.

[0122] In step S905, the device obtains information for accessing a service entity. To this end, according to one embodiment, the device may transmit an inquiry message and other additional request messages to a registry using identification information for the service entity. In this case, the request message includes an indicator for at least one service entity, and the device receives information for accessing the service entity corresponding to the indicator as a response to the request message. According to another embodiment, the information for accessing may be included in the information received in step S903. In this case, the device identifies the information for accessing the corresponding service entity in the received information. For example, the information for accessing may include a CoA.

[0123] In step S907, the device uses the service entity to access the service. That is, the device accesses the service entity based on the information obtained in step S905 and receives the service by exchanging necessary data with the service entity.

[0124] As described with reference to FIG. 9, the device may request information about a service entity (e.g., CSE) by transmitting an inquiry message. In this case, the inquiry message may be transmitted in response to the satisfaction of predefined conditions. For example, the inquiry message may be transmitted in response to the device moving its location or requiring a service change.

[0126] FIG. 10 is a diagram illustrating the operation method of a device providing services in an M2M system according to the present disclosure. The operating entity of FIG. 10 may be a CSE of the device providing services. In the following description, the operating entity of the procedure of FIG. 10 is referred to as the 'device'.

[0127] Referring to FIG. 10, in step S1001, the device transmits a request message for registration. In other words, the device transmits a request message containing descriptive information to a registry in order to register its descriptive information in the registry. The descriptive information includes information about IoT services that can be provided by the device. According to one embodiment, the request message may further include at least one of information specifying a resource to store the descriptive information and information indicating whether the device's service is available.

[0128] In step S1003, the device receives a confirmation message regarding the registration result. The device receives a response indicating that the device's descriptive information has been registered in the registry. That is, the confirmation message notifies that the device's descriptive information has been stored in the registry and has become available for provision upon request by another device.

[0129] In step S1005, the device checks whether a request message for a service is received from another device. Here, the request message for a service may be generated based on information about a device registered in the registry.

[0130] When a request message for a service is received, in step S1007, the device provides the service to another device. The device provides the service by allowing the other device to connect and exchanging necessary data.

[0131] Although not illustrated in FIG. 10, after the device is registered with the registry, the device may perform further actions to notify the registry of its status. Actions to notify the status include responding to a request from the registry with the device's service-related status. Specifically, upon receiving a message for an active check from the registry, the device may send a message to the registry as a response indicating its current status (e.g., whether service is available).

[0132] Although not illustrated in FIG. 10, the device may perform a preliminary operation to obtain information about a registry. The preliminary operation may be performed between the device's AE and CSE. For example, the AE may request the CSE to register descriptive information in the registry. At this time, the AE may provide the CSE with information about the registry (e.g., access address). Accordingly, in the aforementioned step S1001, the CSE may generate a request message containing descriptive information in response to the AE's request and transmit the request message to the registry.

[0134] FIG. 11 is a diagram illustrating the operation method of a device that provides information about a device providing services in an M2M system according to the present disclosure. The operating entity of FIG. 11 may be a CSE of a device that performs a registry function. In the following description, the operating entity of the procedure of FIG. 11 is referred to as a 'device'.

[0135] Referring to FIG. 11, in step S1101, the device registers and manages information about a service entity. The device may register descriptive information about a service provided by the service entity in response to a request from the service entity. Subsequently, the device may check the status of the registered service entity periodically or non-periodically.

[0136] In step S1103, the device checks whether it receives a query message regarding a service entity. The device may receive a query message regarding the search for a service entity from another device. The query message may include information about search criteria. For example, the search criteria may be related to at least one of a device, a service, a service entity, or a search result. Specifically, the search criteria may be at least one of the device's location, a specific service, a category of a specific service, all available services, or available service entities.

[0137] When an inquiry message regarding a service entity is received, in step S1105, the device transmits information regarding the service entity. Specifically, the device that received the inquiry message may identify at least one service entity among the registered service entities based on search criteria and transmit a message containing information regarding the identified at least one service entity. The information regarding the service entity may include a list containing at least one service entity. Here, the at least one service entity included in the list is a service entity registered in the registry.

[0138] In step S1107, the device provides information for accessing a service entity. To this end, according to one embodiment, the device may receive an inquiry message and other additional request messages. In this case, the request message includes an indicator for at least one service entity, and the device transmits information for accessing the service entity corresponding to the indicator as a response to the request message. According to another embodiment, the information for accessing may be included in the information received in step S903. In this case, step S1107 may be included in the aforementioned step S1105 or performed separately. For example, the information for accessing may include a CoA.

[0140] FIG. 12 is a diagram showing the configuration of an M2M device in an M2M system according to the present disclosure. The M2M device (1210) or M2M device (1220) shown in FIG. 12 can be understood as hardware that performs at least one of the functions of the aforementioned AE, CSE, and NSE.

[0141] Referring to FIG. 12, an M2M device (1210) may include a processor (1212) that controls the device and a transceiver (1214) that transmits and receives signals. In this case, the processor (1212) can control the transceiver (1214). Additionally, the M2M device (1210) can communicate with another M2M device (1220). The other M2M device (1220) may also include a processor (1222) and a transceiver (1224), and the processor (1222) and the transceiver (1224) can perform the same functions as the processor (1212) and the transceiver (1214).

[0142] For example, the aforementioned transmitter and receiver may each be one of the M2M devices (1210 and 1220) of FIG. 12. Additionally, the devices (1210 and 1220) of FIG. 12 may be other devices. For example, the devices (1210 and 1220) of FIG. 12 may be devices such as a communication device, a vehicle, or a base station. That is, the devices (1210 and 1220) of FIG. 12 refer to devices capable of performing communication and are not limited to the embodiments described above.

[0144] The embodiments of the present invention described above may be implemented through various means. For example, the embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.

[0145] As described above, the detailed description of the preferred embodiments of the present invention disclosed is provided to enable those skilled in the art to implement and practice the present invention. Although the above description refers to preferred embodiments of the present invention, those skilled in the art will understand that various modifications and changes can be made to the present invention without departing from the spirit and scope of the present invention as described in the following claims. Accordingly, the present invention is not intended to be limited to the embodiments shown herein, but to be given the broadest possible scope consistent with the principles and novel features disclosed herein. Furthermore, although preferred embodiments of the present specification have been illustrated and described above, the present specification is not limited to the specific embodiments described above, and various modifications can be made by those skilled in the art without departing from the gist of the present specification as claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the present specification.

[0146] In addition, both product inventions and method inventions are described in this specification, and the descriptions of both inventions may be applied supplementarily as necessary.

[0147] Furthermore, the present invention has been described with reference to its preferred embodiments. Those skilled in the art will understand that the present invention may be implemented in modified forms without departing from the essential characteristics of the invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the invention is defined by the claims, not by the foregoing description, and all variations within the scope of the claims should be interpreted as being included in the invention. Explanation of the symbols

[0148] 1210: M2M device 1212: Transmitter / Receiver 1214: Processor 1220: M2M device 1222: Transmitter / Receiver 1224: Processor< / remotecse> < / csebase> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / platformregistry> < / group> < / groupannc> < / container> < / containerannc> < / resourcetype> < / resourcetype> < / platformregistry>

Claims

Claim 1 delete Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 delete Claim 7 A method for providing services by an M2M device in an M2M (Machine-to-Machine) system comprises: transmitting a first message requesting a registry to register information about the M2M device; receiving a second message from the registry confirming the completion of the registration; receiving a third message requesting services from another M2M device based on information about the M2M device registered in the registry; and providing services to the other M2M device; wherein the step of transmitting the first message comprises: receiving a request message from the registry requesting the registration of description information into the registry; and generating and transmitting the first message in response to the request message from the registry, wherein the request message includes a request for the publication of the M2M device to the registry and address information of the registry. Claim 8 A method for providing a service according to claim 7, wherein the first message includes the descriptive information of the M2M device, and the descriptive information includes information about a service that can be provided by the M2M device. Claim 9 A method for providing a service according to claim 8, wherein the first message comprises at least one of information specifying a resource for storing the descriptive information and information indicating whether the service of the M2M device is available. Claim 10 In Paragraph 9, the above-mentioned resource is, <platformregistry> A method of providing a service that includes resources.< / platformregistry> Claim 11 A method for providing a service according to claim 7, further comprising: receiving a fourth message for a liveness check from the registry; and transmitting a fifth message indicating the service availability status of the M2M device in response to the fourth message. Claim 12 delete Claim 13 delete Claim 14 An M2M device providing services in an M2M (Machine-to-Machine) system comprises: a transceiver for transmitting and receiving signals; and a processor for controlling the transceiver; wherein the processor transmits a first message requesting a registry to register information about the M2M device, receives a second message from the registry confirming the completion of the registration, receives a third message requesting a service from another M2M device based on information about the M2M device registered in the registry, and provides a service to the other M2M device, wherein the processor receives a request message from the registry requesting the registration of description information into the registry, and in response to the request message from the registry, generates and transmits the first message, wherein the request message includes a request for the publication of the M2M device to the registry and address information of the registry. Claim 15 In paragraph 14, the first message comprises the descriptive information of the M2M device, wherein the descriptive information comprises information about a service that can be provided by the M2M device. Claim 16 In paragraph 15, the above-mentioned first message comprises at least one of information specifying a resource to store the above-mentioned descriptive information and information indicating whether the service entity is available for service, in an M2M device. Claim 17 In Paragraph 16, the above resources are, <platformregistry> M2M device containing resources.< / platformregistry> Claim 18 In paragraph 14, the processor receives a fourth message for a liveness check from the registry and transmits a fifth message indicating the service availability status of the M2M device in response to the fourth message. Claim 19 delete Claim 20 delete

Images