KR20180106934A - Methods for processing group resources in M2M system And Apparatuses thereof - Google Patents

Abstract

The present disclosure relates to a technology for processing group resources in a machine-to-machine communication (M2M) system, and more particularly, to a technique for preventing errors from being generated in advance by processing group resources more accurately in generation and update of group resources. According to an embodiment, a method of processing group resources in an M2M system includes steps of: receiving a request message requesting a group resource processing operation; determining whether each member is accessible based on at least one piece of member identification information included in a group resource; generating response status code information based on at least one piece of information included in the result of determining whether each member is accessible and the request message; and transmitting a response message including the response status code information for the request message.

Description

[0001] The present invention relates to a method and an apparatus for processing a group resource in an M2M system,

The present disclosure relates to a technology for processing group resources in a machine-to-machine communication (M2M) system, and more particularly, to a technology for preventing group errors from being generated in advance by processing group resources more accurately in generating and updating group resources.

"Machine to Machine Communication" or MTC, "Machine Type Communication" or "Smart Device Communication" or "Machine oriented communication" or "Internet of Things" In which communication is performed without intervening in the network.

Since object communication does not normally perform communication and application control directly by a person, transmission and reception methods and procedures are required to exchange messages between objects. There is also a need for a protocol for smooth message exchange between M2M devices.

Particularly, in accordance with popularization of IoT devices, a plurality of object communication devices are used in the home and office, and a plurality of object communication devices performing the same or similar functions are deployed for a certain purpose. For example, each lighting device may include an object communication module, and multiple lighting devices within the home may function as the object communication device.

To this end, it is necessary to manage the object communication apparatuses performing the same or similar functions as a group, and control the object communication apparatuses included in the group at a time through group control.

However, as the number of object communication devices increases, various problems may arise, such as differences in protocol of each object communication device, occurrence of a failure, or network connection. At present, when such a problem occurs in terms of group resource management in object communication, it is impossible to control a plurality of object communication apparatuses through a group, and such a problem can be confirmed in the event of attempting control.

In the present embodiment, which is devised from the background described above, in the process of creating or updating a group resource in an M2M environment, it is checked whether an individual M2M device included in a group resource has a problem or not, And an apparatus and method for the same.

According to an embodiment of the present invention, there is provided a method of processing a group resource by a machine-to-machine communication (M2M) device, the method comprising: receiving a request message requesting a group resource processing operation; Generating response state code information based on at least one of information on the connection availability result and the request message based on the above-described member identification information, determining whether or not each member is connectable, And transmitting a response message including the code information.

According to an embodiment of the present invention, there is provided a machine-to-machine communication (M2M) apparatus for processing a group resource, the apparatus comprising: a receiver for receiving a request message for requesting a group resource processing operation; A control unit for checking whether or not each member is connectable and generating response status code information based on at least one of the connection availability result and information included in the request message, and a response message including response status code information for the request message And a transmitter for transmitting the M2M device.

The present embodiment described above provides an effect of enabling a problem solving operation in advance by confirming in advance whether or not each M2M device in a group resource has a problem in group resource processing operation such as generation or update of a group resource.

In addition, this embodiment provides an effect of improving the user reliability of the entire M2M system by preventing the post-event detection or the post-event occurrence in advance.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating the M2M system from a high level functional view.
FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.
FIG. 3 is an exemplary diagram illustrating a procedure for transmitting a request message and receiving response information in the M2M system.
FIG. 4 is a diagram illustrating a functional structure of a common service entity according to an embodiment.
FIG. 5 is a view for explaining an example of using information of an M2M device using group resources according to an embodiment.
6 is a diagram exemplarily showing a configuration of a conventional group resource.
FIGS. 7 and 8 are diagrams for explaining attribute information of a conventional group resource.
FIG. 9 is a diagram for explaining a problem that may occur in the conventional group resource processing operation.
10 is a view for explaining a group resource processing operation of the M2M apparatus according to an embodiment.
11 is a view for explaining a group resource processing operation of the M2M apparatus according to another embodiment.
12 and 13 are diagrams for explaining a request message processing operation of the M2M apparatus according to an embodiment.
FIG. 14 is a diagram for explaining a type of a response status code indicating a success process according to an embodiment.
15 is a diagram for explaining a type of a response status code indicating failure processing according to an embodiment.
FIG. 16 is a diagram illustrating a configuration of a group resource according to an exemplary embodiment.
17 is a diagram for explaining attribute information of a group resource according to an embodiment.
18 is a diagram for explaining resource specific attributes of a group resource according to an embodiment.
19 is a view for explaining a problem of primitive content of group resources according to the related art.
20 is a diagram illustrating exemplary primitive content of a group resource according to an exemplary embodiment of the present invention.
FIG. 21 is a view for explaining values included in consistencyStrategy attribute information according to an embodiment.
22 is a view for explaining an M2M device according to an embodiment.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be "connected," "coupled," or "connected. &Quot;

Embodiments of the present invention will be described with reference to object communication. Object communication is variously called M2M (Machine to Machine communication), MTC (Machine Type Communication), IoT (Internet of Things), Smart Device Communication (SDC), or Machine Oriented Communication . OneM2M has recently introduced many technical issues related to object communication. Object communication refers to various communication in which communication is performed without a person intervening in the communication process. In the field of telecommunication, there are various fields such as energy field, enterprise field, healthcare field, public service field, residential field, retail field, transportation field, and others Field, and so on. The present invention includes the above-mentioned fields, and is applicable to other fields.

1 is a diagram illustrating a high-level functional view of an M2M system according to an embodiment.

An application entity (AE) 110 provides application service logic for an end-to-end M2M solution. For example, a fleet tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application.

The Common Services Entity (CSE) 120 may be used for various services such as an energy field, an enterprise field, a healthcare field, a public service field, a residential field, ), Transportation (transportation), and other fields.

This service function is exposed as a different function through reference points Mca, Mcc, and uses the base network service using the reference point Mcn. One example of the common service entity may be data management, device management, M2M subscription management, location service, and the like. The subfunctions provided by the CSE can be logically understood as a CSF (Common Service Function). Some of the CSFs within the CSE of oneM2M node are mandatory and some may be optional. Similarly, the subfunctions in the CSF may also be mandatory or optional.

An underlying network services function (NSF) 130 provides services to the common service entity. Examples of services include device management, location services and device triggering.

Reference Points are supported in a common service entity (CSE), and the Mca reference point is a reference point for providing object communication between an application entity and a common service entity. The Mcc reference point is a reference point for providing communications between the two common service entities. The Mcn reference point is a reference point for providing object communication between a common service entity and one network service entity.

More specifically, the Mca reference point allows one application entity (AE) to use the services supported by the common service entity. The services provided through the Mca reference point are dependent on the functionality provided by the common service entity, and the application entity and the common service entity may reside in the same physical entity or in different physical entities. The Mcc reference point enables such use by a common service entity that wishes to use the services of other common service entities that provide the necessary functionality. The services provided through the Mcc reference point are dependent on the functionality provided by the common service entity. Mcc reference points can be supported between different M2M nodes. The Mcn reference point enables such use by a common service entity that wishes to use the service object of the underlying network providing the necessary functionality, which provides services other than transport and connection. The instance of the Mcn reference point is implemented dependent on the service provided in the underlying network. Information exchange between two physical M2M nodes can use the transport and connectivity services of the underlying network to provide basic services.

In this specification, a common service entity can be described as a CSE, and a network service entity can be described as a network service entity (NSE). In this specification, the M2M device means CSE or AE, means a device including CSE or AE, and means a device or terminal constituting the M2M system.

FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.

Referring to FIG. 2, an infrastructure node 250 performs a server function necessary to provide M2M communication. The originating node 250 is comprised of an originating node application entity (AE) 252 and an originating node common service entity (CSE) 254. Based node common service entity 254 is configured using various resources. 252 and 254 are divided through an Mca reference point and a message for communication of objects, particularly a request message for creating, deleting, updating, retrieving, and notifying the scheduler resource And for constructing and processing response messages.

The relay node 200 relays the M2M communication or the Internet of Things communication between the application service node 220 and the base node 250. The relay node 200 includes a relay node application entity 202 and a relay node common service entity 204. The relay node common service entity 204 is configured using various resources. 202 and 204 are divided through Mca reference points and 254 and 204 are classified using Mcc reference points and messages necessary for object communication, in particular, create, delete, update, Used to construct and process request and response messages to retrieve and notify.

The application service node 210 may include an application entity 212 and a relay node common service entity 214. The application entity 212 processes the application functions required for the purpose of the device. The common service entity 214 of the application service node 210 is configured using various resources. 212 and 214 are divided through Mca reference points and 214 and 254 are classified using Mcc reference points and messages necessary for object communication, in particular, create, delete, update, Used to construct and process request and response messages to retrieve and notify. Meanwhile, the application service node 220 may perform the object communication function with the base node 250 through the relay node 200. The difference between 210 and 220 is that the communication interfaces constituting the node are different. For example, the 220 communicates with 200 through 200 using an interface capable of a near-field communication such as Bluetooth, ZigBee, Zwave, and WiFi. On the other hand, the 210 communicates with 250 using a communication interface such as 3G, LTE, 5G, Ethernet, Gigabit Ethernet, ADSL and the like.

The application dedicated nodes 230 and 240 do not have a common service entity but do object communication using only the application entity 242. [ 230 is used to communicate with 250 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, ADSL and the like, and 240 is used to communicate with 250 through 200 using an interface capable of Bluetooth communication, ZigBee, Zwave, WiFi, Lt; / RTI >

As described in FIG. 2, the M2M system may be configured as at least one of an infrastructure node, a relay node, an application service node, and an application dedicated node, and each node may be configured to include a CSE or an AE. CSE and AE can communicate with other CSEs or AEs through their respective reference points.

Referring to FIG. 3, the originator 300 transmits a request message to a receiver 310 (S320). The sender 300 and the receiver 310 may each be an M2M device and may be CSE or AE as described above. Also, the sender 300 and the recipient 310 may be nodes or servers or devices, including CSE or AE.

The request message may include one or more parameters. For example, the request message may include mandatory and optional parameters. For example, the From side parameter, the To parameter, the Request Identifier parameter and the Operation parameter are included as mandatory parameters. The From parameter includes information about the sender sending the message, and the To parameter includes information about the recipient receiving the message. The Request Identifier parameter contains unique identification information for identifying the request message. In addition, the operation parameter includes information for distinguishing the requested operation from the request message. The operation parameter may be set to one of Create, Retrieve, Update, Delete, and Notify. In addition, optional parameters may be added to control various operations of the request message. For example, the optional parameters of the response type include a blocking processing method, a non-blocking blocking request method, a non-blocking blocking method, a non-blocking blocking method, a flexBlocking method, .

When the request message is received, the receiver 310 performs an operation for processing the request message (S330). For example, the receiver 310 can check whether the sender 300 having transmitted the request message has the right to the request. When it is determined that the sender 300 has the authority for the request, the request message is processed after confirming whether the requested resource exists. Alternatively, the receiver 310 may perform a corresponding operation according to the operation parameter of the request message. For example, when an operation parameter is set to be generated and a subscription function for instructing the sender 300 to inform the sender 300 of a change, addition, deletion, or the like of specific data occurs, the receiver 310 transmits the subscription information And notifies the sender 300 of the occurrence of an event such as change, addition, deletion, etc. in the data corresponding to the subscription information.

The receiver 310 generates processing result information according to the request operation and includes it in a response message and transmits it to the sender 300 (S340). The step S340 may be performed before the step S330. That is, when the receiver 310 receives the request message, it generates an ACK response message indicating simple reception of the ACK response message, and transmits the ACK response message to the sender 300, and then performs a step S330 to process the request message.

4 is a diagram illustrating a common service entity according to an exemplary embodiment of the present invention. Fig. 4 includes a function of processing identification information.

The functions provided by the common service object can be summarized as shown in FIG. 4, and can be classified into Addressing & Identification, Application and Service Layer Management, Data Management & Repository, Location, Security, Communication Management / Delivery Handling, Registration, Service Session Management, Device Management, Subscription / Notification, Connection Management Service Charging / Accounting, Network Service Exposure / Service Execution and Triggering, Group Management, and so on.

Each of the functions will be described as follows.

Application and Service Layer Management (ASM) is responsible for managing AEs and CSEs for ADN, ASN, MN, and IN, including configuration, troubleshoot, upgrading, and upgrading of AEs. .

Communication Management and Delivery Handling (CMDH) is responsible for communication between other CSEs, AEs, and NSEs. CMDH is responsible for storing the communication requests at which time to communicate using which communication connection (CSE-CSE communication), when it is needed and when it is allowed, and when the transmission of the communication is postponed. CMDH is performed according to the provisioning policy and delivery handling parameters specific to each request for communication. Based network data transmission service, the underlying network can support the same forwarding handling function. In this case, the CMDH can use the underlying network and can act as a front end accessing the same forwarding handling function to the underlying network.

Data Management and Repository (DMR) allows M2M applications to exchange data with other objects. The DMR CSF provides the ability to provide and coordinate data storage. It also includes the ability to collect and combine large amounts of data, convert data to a specific format, or store data for analysis and semantic processing. "Data" means raw raw data that is transparently extracted from an M2M device, or may refer to data processed or combined and processed by an M2M entity. Collecting large amounts of data constitutes what is known as Big Data Storage.

DMG (Device Management) The CSF is responsible for managing the device functions of devices in the MN, device nodes, and M2M local network. It enables device management to provide one or more of the following functions: Installation and configuration of application software, configuration settings and provisioning, firmware update, logging and monitoring and analysis, topology management of local networks, and devices in local network management.

The DIS (Search) CSF is responsible for retrieving information and resources granted in the given scope and subject (including those allowed in the M2M service subscription) and within the given scope for the Originator's request. The sender can be an application or another CSE. The scope of the search may be one CSE or multiple CSEs. The search results are delivered to the caller.

Group Management (GMG) handles the group associated with the request. Requests are sent for the management of group and group membership, and are also responsible for the bulk operations supported by the group. When adding or deleting members to a group, you need to make sure that the members conform to the purpose of the group. Bulk operations include read, write, subscribe, notify, and device management. The request or subscription is made through the group, and the group is responsible for combining these requests and notifications. Members of a group have the same role in access rights to resources. In this case, access control is done by the group. If the underlying network provides broadcasting and multicasting capabilities, the GMG CSF should use these functions.

LOC (Location) The CSF enables the M2M AE to acquire the geographical location information of M2M nodes (eg ASN, MN) for location based services. This location information may be requested from an M2M AE that is in the same or a different M2M node.

NSE (Network Service Exposure) The CSF manages communication with the underlying network to access network service functions through the Mcn reference point on an available or supportable way for service requests from the M2M system on behalf of the M2M application. The NSE CSF conceals other CSFs and AFs from specific technologies and mechanisms supported in the underlying network. The network service functions provided from the underlying network include, but are not limited to, device triggering, small data transfer, location notification, policy rule setting, location query, IMS service, device management and the like. These functions do not include common transport services

REG (Registration) is responsible for handling applications or other CSEs to register with the CSE, which allows the registration of entities that want to use the services provided by the CSE. The REG CSF handles not only device registration for the CSE, but also device property / attribute registration.

SEC (Security) provides sensitive data handling, security operation, security association setting, authorization and access control, and identification protection. The sensitive data handling functionality provided by the SEC CSF provides the ability to protect local credentials that require security during storage and manipulation. Sensitive data handling also uses security algorithms. This feature supports separate security environments with different cryptographic techniques. The security operations function provides the following functions, first providing the creation and operation functions of a dedicated security environment to be supported by sensitive data handling functions. It also supports post provisioning of root credentials protected in a secure environment and supports the provisioning and operation of subscriptions related to M2M services and M2M application services. The security association setting function establishes a security association between M2M nodes to enable confidentiality, integrity, authentication, and authorization. Authorization and access control functions control the access of services and data to authorized entities according to the provisioned security policies and assigned roles. The unique identifier of the entity is used for authorization, and the identity protection function can provide anonymity that serves as a temporary identifier so that it is not linked to the actual identity information associated with the entity or user.

Service Charging and Accounting (SCA) provides billing for the service layer. Supports different billing models, including online and offline billing. The SCA CSF acquires billable events, stores information, and generates billing records and billing information. The SCA CSF can interact with the billing system of the underlying network. However, the SCA CSF is responsible for generating and recording billing information at the final service level. The SCA CSF of the base node or service layer charging server is responsible for handling billing information for billing.

SSM (Service Session Management) The CSF manages M2M service sessions that are end-to-end service layer connections. The SSM CSF manages M2M service sessions between M2M applications, or between M2M applications and CSEs, or between CSEs. Management of the M2M service session includes management of the session state, establishment and authentication of the session, management of the underlying network connection and service related to the session, coordination of the session expansion of the CSE multi-hop cse, . Within a given M2M service session, the SSM CSF uses the CMDH CSF in the local CSE to send / receive messages to / from the next hop CSE or application. The SSM CSF uses the SEC CSF for session credentials for session participants and for session management related to authentication. The SSM CSF generates session-specific billing events and also communicates with the SCA CSF in the local CSE.

Subscription and Notification (SUB) provides notifications to maintain subscriptions and tracks changes in resources (for example, deletion of resources). The subscription of the resource is initiated by the M2M AE or CSE and is authorized by the hosting CSE. During an active subscription, the hosting CSE sends a notification to the address that the resource subscriber wants to receive in the event of a change in the subscribed resource.

4 and the description thereof are embodiments for implementing a common service entity, and the present invention is not limited thereto.

An identifier that can be applied to the present embodiments will be described as follows. The M2M identifier includes an M2M Service Provider Identifier (M2M-SP-ID), an App-Inst-ID (Application Instance Identifier), an App-ID (Application Identifier), a CSE-ID (CSE Identifier), an M2M- A Node Identifier / Device Identifier, an M2M Service Subscription Identifier (M2M-Sub-ID), and an M2M-Request-ID (Request Identifier).

oneM2M is a requirement that must be fulfilled to implement the system. It includes overall system requirements, management requirements, data model & semantics requirements, security requirements Requirements, Charging Requirements, and Operational Requirements.

This document focuses on M2M system technology, especially oneM2M service platform technology. However, this description is not limited to the M2M service platform technology, but is applicable to all systems and structures that provide inter-device communication, i.e., object communication, and communication operations occurring in these systems.

The M2M device in this specification describes the various nodes such as AE, CSE, NSE, and the like, and for the sake of convenience, the description will be made with reference to the hosting CSE. However, the present invention is not limited thereto. That is, the M2M device refers to a constituent device that constitutes the M2M system, and refers to various nodes, devices, and entities that receive a request message, perform processing thereon, and transmit a response message.

In addition, the member described below may mean an AE included in the group resource, and may mean an M2M device. Accordingly, the member can be variously set according to the purpose of generating the group resource and the target, and can be various objects included in the corresponding M2M system.

The present disclosure aims at processing and controlling group resources without error in the M2M system and recognizing whether or not the members included in the group resources can be connected in advance to prevent errors that may occur afterwards.

The IoT or M2M system may be composed of similar types of equipment. For example, in an M2M system using a smart meter, it is possible to receive data obtained from a plurality of smart meters. In addition, the M2M system can request that the M2M application program transmit data to the M2M application in the M2M application and the M2M application in the M2M gateway group specified by the M2M application in a manner independent of the underlying network.

FIG. 5 is a view for explaining an example of using information of an M2M device using group resources according to an embodiment.

Referring to FIG. 5, the data center 550 may request data directly from the smart meter 501 and obtain the sensed data from the smart meter 501, such as the procedure of A1, A2. The smart meter 501 and the data center 550 are all M2M devices constituting the M2M system.

Alternatively, the data center 550 may request data to the data merge point entity 510 without performing data request and data reception operations directly to the smart meter 501, such as the procedures of B11, B12, B21, And may receive data from the merge point entity 510. This can be applied to a procedure for acquiring data from an M2M system in a region that is configured independently of the basic network described above.

For example, the data merge point object 510 may request, collect and store data from a plurality of smart meters 502, 503, and 504 and may receive data from the data center 550 at the request of the data center 550, have.

As such, unlike an individual M2M device in which a plurality of M2M devices of the same or a similar type exist, the data center directly requests data, but utilizes an M2M device (e.g., a hosting CSE) to collect and store data It can be efficient.

To do this, it is necessary to collectively create and manage the same or similar type of data as group resources by the M2M device.

Accordingly, the group resource is a resource for grouping and managing a plurality of data as needed by the M2M device, and the group resource may be configured to include detailed attribute information and an attached resource.

6 is a diagram exemplarily showing a configuration of a conventional group resource.

Referring to FIG. 6, in the conventional M2M system, the M2M device manages and manages attribute information and ancillary resources in group resources.

For example, a group resource may contain nine unique attribute information and four attached resources. In addition, the group resource may further include general attribute information, common attribute information, and attached resource information that are commonly included in individual resources in the M2M system.

As an example, universal attribute information may be composed of resourceType, resourceID, resourceName, parantID, expirationTime, creationTime, and lastModifiedTime.

In another example, common attribute information may be comprised of labels, accessControlPolicyIDs, announceTo, announcedAttribute, dynamicAuthorizationConsultationIDs, and creator.

As another example, the group resource unique attribute information may be composed of memberType, currentNrOfMembers, maxNrOfMembers, memberIDs, membersAccessControlPolicyIDs, memberTypeValidated, consistencyStrategy, groupName, and semanticSupportIndicator as shown in FIG.

As another example, the group resource sub resource information may be composed of <semanticDescriptor>, <subscription>, <fanOutPoint>, and <semanticFanOutPoint>.

FIGS. 7 and 8 are diagrams for explaining attribute information of a conventional group resource.

As shown in FIG. 7 and FIG. 8, the attribute information of the conventional group resource can be determined as a data type, a read and a write right, a mandatory inclusion and an optional inclusion. In some examples, the member type information (memberType) is attribute information indicating whether or not the resource types of the respective members in the group are the same or different. The current member number information (currentNrOfMembers) is attribute information indicating information on the number of members in the group. Similarly, the member identification information memberIDs is attribute information indicating a list of identifiers for the members (or member resources) included in the group. The meaning of the individual attribute information can be referenced in Figs. 7 and 8 and the OneM2M TS document TS-0004 document.

As such, the M2M device can utilize group resources to manage data. In order to utilize the group resources, it is necessary to create the group resources and update the generated group resources as required or as needed. However, conventionally, there is a possibility that an error may occur in generating or updating a group resource. In addition, in the related art, it is not possible to store and manage problems occurring in the process of creating or updating a group resource. A specific problem will be described with reference to FIG.

Hereinafter, the process of generating a group resource will be mainly described, but the same process can be applied to a process for an update operation.

 FIG. 9 is a diagram for explaining a problem that may occur in the conventional group resource processing operation.

Referring to FIG. 9, upon receiving a request message for requesting to generate a group resource, the M2M device performs redundancy checking to determine whether the member identification information to be included in the group resource is duplicated (S900). If there is duplicate member identification information, duplicate member identification information is deleted (S905). If there is no duplicate member identification information, the member number information is compared (S910).

For example, in step S910, it is possible to determine whether the current member count information is less than the maximum member count information. If it is determined that the current member count information is greater than or equal to the maximum member count information, a response status code 6010 indicating a process failure is generated and a response message is transmitted to the caller (S915). If the current member count information is less than the maximum member count information, the member type information is checked to determine whether the types of the member resources in the group resource are the same or not (S920).

If the type of each member resource is different according to the determination result in step S920, all the member identification information is checked (S925). However, conventionally, there has been a problem that the group resource can not be successfully processed because the M2M device does not perform an operation for generating another group resource after step S925.

Otherwise, if the type of each member resource is all the same according to the determination result in step S920, it is checked whether the group resource is a virtual resource (S930). If the group resource is not a virtual resource, the member resource for each member identification information is inquired (S945). Step S945 may be omitted as necessary.

Alternatively, if the group resource is a virtual resource, it is checked whether generation of the attached virtual resource is permitted to the upper resource (S940), and if yes, the process proceeds to S945. However, conventionally, when the virtual resource is not allowed in step S940, a separate operation for the M2M device is not defined, which causes the M2M device to generate an error.

In step S950, it is determined whether the corresponding M2M device is authorized in step S945 or not. If the M2M device is not authorized, a response status code indicating a process failure is set and a response message is transmitted in step S955. If the M2M device is authorized, it is checked whether the individual member identification information included in the group resource can be accessed (S960). If it is determined that access to all members to be included in the group resource is possible, the value of the memberTypeValidated attribute information is set to TURE (S970). However, after step S970, the operation of the M2M device is not clearly disclosed.

If it is determined that the connection to at least one of the members to be included in the group resource is impossible, the M2M device sets the value of the memberTypeValidated attribute information to FALSE (S965) and checks the consistencyStrategy attribute information (S975). The consistencyStrategy attribute information can be set to three values, and S980, S985, and S990 can be processed according to each set value.

For example, if the consistencyStrategy attribute information is set to ABANDON_MEMBER, the member identification information that can not be connected is deleted (S980), and the step S970 is performed. If the consistencyStrategy attribute information is set to SET_MIX, the member type attribute information is set to MIXED (S985), and step S970 is performed. When the consistencyStrategy attribute information is set to ABANDON_GROUP, the group resource processing operation is interrupted (S990).

Conventionally, in the case of changing and setting the member type information in step S985, there is a problem in that information on members that can not be connected is not separately managed, and there is a problem that the member having a problem is kept in the group resource. In step S990, The sender does not know the result of the group resource processing request because there is no procedure for generating the forwarding or response status code.

In other words, conventionally, when the memberIDs are of a single type, if the consistencyStrategy is SET_MIXED, there is no procedure to process and an error occurs. Also, if the memberIDs are a single type or a complex type, an error occurs because there is no procedure for processing when the network connection is not established. Also, when the consistencyStrategy is SET_MIXED, an error occurs due to the implicit processing.

As described above, in the conventional group resource processing procedure, when there are various problems and an error occurs, and there is no management about whether there is a member that can not be connected, which member is not, and so on, There was a problem afterwards.

In order to solve this problem, the present disclosure is directed to a method for preventing the occurrence of an error by changing and supplementing a processing operation of a group resource and clearly managing the status of members in the group resource.

10 is a view for explaining a group resource processing operation of the M2M apparatus according to an embodiment.

Referring to FIG. 10, a Machine to Machine communication (M2M) apparatus may perform a step of receiving a request message requesting a group resource processing operation to process a group resource (S1000). For example, the M2M device may receive a request message requesting the creation or update of group resources from another M2M device or a node of another M2M system. As described with reference to FIG. 3, the request message may include various parameters. In addition, the request message may include parameters and attribute information necessary for generating a group resource.

For example, the request message may include at least one of member type information, current member count information, maximum member count information, at least one member identification information, consistency strategy information, and execution instruction information.

Then, the M2M device can perform the step of checking whether or not each member can be connected based on the one or more member identification information included in the group resource (S1010). The M2M device performs a requested processing operation on the group resource using parameters and attribute information included in the request message.

For example, the M2M device can check whether or not each member to be included in the group resource can be connected. In order to confirm whether or not the connection is possible, the M2M device can confirm whether or not the resource of the corresponding member identification information can be accessed by using the member identification information of each member.

Depending on the connection result, all the members to be included in the group resource may be accessible, or some members may be temporarily or permanently disconnected due to various reasons such as a network problem, a power problem of the member device, and a failure of the member device.

The M2M device may perform the step of generating response status code information based on at least one of the connection availability result and the information included in the request message (S1020). The M2M device may perform the request processing operation and generate the response status code information according to the connection availability result that is determined in step S1010.

For example, if it is determined that all of the one or more member identification information included in the group resource can be accessed, the M2M device generates or updates the group resource according to the type of processing operation of the group resource, And the identifier can be generated. For example, when the request message requests the generation of the group resource, the M2M device generates the group resource by including the member identification information to be included in the corresponding group resource in the group resource attribute information, and instructs the processing success of the request message A response status code (for example, 2000) can be generated. When the request message requests updating of the group resource, the member included in the group resource is updated according to the instruction indicated by the request message, and a response status code indicating the success of the process is generated.

As another example, if the M2M device determines that at least one of the member identification information included in the group resource is inaccessible, the M2M device processes the attribute information of the group resource to include the member identification information that can not be accessed, The code can be generated by setting it as an identifier indicating success in processing. For example, when the connection to some members to be included in the group resource is impossible, the M2M device generates the group resource including the member to be included in the group resource, and stores the member identification information in the separate attribute information Group resources can be created. As an example, attribute information for storing impossible member identification information may be unreachableMemberIDs. The member identification information that can be separately accessed can be stored in the member ID attribute information to generate the group resource. That is, the M2M device can distinguish member identification information to be included in the group resource according to connection availability, store the member identification information in separate attribute information, and perform a request processing operation. In this case, since the request processing operation for the group resource has been performed, the response status code can be generated by a code indicating the success of the processing. However, a response status code indicating success in processing when all the members are connectable and a response status code indicating a success in processing in the case where some members can not be connected may be set to be different from each other as needed.

As another example, if it is determined that at least one member identification information among the one or more member identification information included in the group resource is inaccessible, the M2M apparatus further uses the consistency strategy information included in the request message to set the value To perform a processing operation and generate a response status code.

For example, when consistency strategy information is set as member exclusion, only the remaining member identification information other than the member identification information determined to be inaccessible among the at least one member identification information included in the group resource is used as the consistency strategy information And generate and update the group resource so that the response status code is set to an identifier indicating the success of the processing. In this case, it is possible to set it differently from the response status code indicating the success of the above-described processing.

As another example of using consistency strategy information, when consistency strategy information is set to group exclusion, the M2M device can generate a response status code by setting it as an identifier indicating failure of processing. In this case, the processing operation of the group resource may fail to generate or update the group resource.

As another example of using the consistency strategy information, when the consistency strategy information is set to a mixed (or composite), the M2M device can further perform the step of confirming the member type information included in the request message. A response status code indicating the success of the process can be distinguished and set according to the value of the confirmed member type information. That is, even when the processing of the group resource is completed in the case where the member type information is single and the member type information is mixed, different response status codes are set and generated, so that the caller can distinguish the same.

As another example of using consistency strategy information, when the consistency strategy information is set to be mixed, the M2M device classifies the response status code into an identifier indicating success or failure of processing according to the value of the execution instruction information included in the request message Can be set. For example, when the consistency strategy information is set to be mixed, the M2M device sets the response status code to an identifier indicating success in processing when the Enforcement attribute information indicating the execution direction information is set to TURE, and when the Enforcement attribute information is FALSE The response status code may be set to an identifier indicating failure in processing.

The response status codes indicating the above-described process success can be set differently for each of the above-described process operations. The response status codes indicating the same process failure can be set differently for each of the above-described process operations. Through this, the sender can confirm various group resource processing situations through the response status code of the response message, and can perform an additional operation to correct the wrong group resource.

The M2M device may perform a step of transmitting a response message including response status code information for the request message (S1030). The M2M device sends a response message containing the response status code indicating the result of the request operation indicated by the request message to the sender when the process success or the process failure is finally determined.

As described above, the response status codes are set to be distinguished from each other according to the result of each processing operation, so that the sender can confirm the processing result in more detail. Meanwhile, the response message includes the same request identifier as the request message, and may include a response status code.

The group resource created or updated through the above-described operation may include current member count information, connectable member identification information and non-connectable member identification information as attribute information. As described above, the group resource in this embodiment includes the unreachableMemberIDs attribute information, so that it can perform the reconnection attempt operation later according to the set value, and can determine whether the caller can not connect, You can also check the information.

In this case, the memberIDs attribute information may include only the identification information of the connectable members. In addition, the attribute information (currentNrOfMembers) indicating the current member number information may be set in conjunction with the number of connectable member identification information. That is, the number of members that can not be connected can be set as the number of connectable member identification information.

As described above, the M2M apparatus according to the present invention confirms whether or not the connection to each member to be included in the group resource is possible, and further generates and manages attribute information according to whether or not the connection is available. In addition, an operation error of the M2M device can be prevented by further utilizing the Enforcement attribute information indicating the execution direction information. On the other hand, each operation of the above-described M2M device can be deleted and reordered as necessary, and the detailed steps of each step or an additional step may be included between each step. The detailed overall operation will be described again with reference to Figs. 12 and 13. Fig.

11 is a view for explaining a group resource processing operation of the M2M apparatus according to another embodiment.

Referring to FIG. 11, the M2M device may further perform a step of comparing current member number information and maximum member number information before confirming whether or not connection is possible (S1100). For example, the M2M device may stop the processing operation of the group resource when the current number of members exceeds the maximum number of members. In this case, the response status code is generated with the identifier indicating the processing failure.

If the current number of members is equal to or less than the maximum number of members, a processing operation for the request message may be performed through steps S1010 to S1030.

Hereinafter, a request message processing procedure including FIGS. 10 and 11 will be described in general.

12 and 13 are diagrams for explaining a request message processing operation of the M2M apparatus according to an embodiment.

Referring to FIG. 12, upon receipt of the request message, the M2M device checks whether the member identification information to be included in the group resource is duplicated (S1200). If there is duplicate member identification information, the M2M apparatus removes the duplicated member identification information (S1205), and compares the current number of members and the maximum number of members of the group resource (S1210). If duplicate member identification information does not exist, step S1210 is performed.

When the number of the current members exceeds the maximum number of members, the M2M device stops the process of the request message and sets a response status code indicating the process failure (S1215). In this case, the response status code may be set to a value indicating that the maximum number of members has been exceeded.

If the current number of members does not exceed the maximum number of members, the M2M device checks whether the virtual resource of the group resource is a virtual resource (S1220). If it is a virtual resource, it determines whether the virtual resource is allowed (S1225). If the virtual resource is not allowed, the M2M device stops processing the request message and sets a response status code indicating the processing failure (S1230). In this case, the response status code may be set to a value indicating that the virtual resource is not allowed.

If it is determined in step S1220 that the virtual resource is not a virtual resource, or if the virtual resource is permitted as a result of the determination in step S1225, the M2M apparatus determines whether or not connection is possible for each member identification information to be included in the group resource (S1240).

If it is determined that all the member identification information included in the group resource can be accessed as a result of the determination as to whether or not connection is possible with respect to each member identification information, the M2M apparatus determines whether the authority of the M2M apparatus exists (S1245) The value of the memberTypeValidated attribute information of the resource is set to TRUE (S1250), and the response status code is set to an identifier (e.g., 2000) indicating successful processing (S1255). The response status code may be included in the response message and sent to the sender. If it is determined that the M2M device does not have the authority, the M2M device sets an identifier indicating the failure of the process for the reason that the M2M device is not authorized as a response status code (S1260).

Alternatively, if it is determined that at least one of the member identification information included in the group resource can not be accessed as a result of the determination of connection availability for each member identification information, the M2M apparatus sets the value of the memberTypeValidated attribute information of the group resource to FALSE S1265).

As described above, the M2M device sequentially processes the group resource by determining whether the resource is redundant, whether it is virtual or not, and whether or not connection is possible, and sets a different response status code for success or failure of the process at each step , The sender can be more clearly informed of the processing type and reason of the group resource.

Hereinafter, the procedure after step S1265 will be described with reference to FIG.

After setting the value of the memberTypeValidated attribute information of the group resource to FALSE, the M2M device checks the consistencyStrategy attribute information of the corresponding group resource included in the request message (S1300). For example, the consistencyStrategy attribute information can be set to one of three types: ABANDON_MEMBER, ABANDON_GROUP, and MIXED. The consistencyStrategy attribute information may be additionally defined as needed.

For example, when the consistency strategy attribute information is set to ABANDON_GROUP, the M2M device discontinues the group resource processing operation (S1305), generates and sets a response status code indicating that the request processing for the group resource fails (S1310) .

As another example, if the consistency strategy attribute information is set to ABANDON_MEMBER, the M2M device removes the non-connectable member identification information (S1315), processes the group resource including only connectable member identification information, and determines that the group resource process request is successful And sets the response status code to be instructed (S1320). However, the response status code in this case can be set separately from the response status code in step S1255. Through this, the sender successfully processes the group resource according to the request message, but can distinguish between the two cases, and may request follow-up action if necessary.

As another example, if the consistency strategy attribute information is set to SET_MIX, the M2M apparatus checks the member type attribute information of the group resource of the request message (S1325). The member type attribute information includes information on whether each member to be included in the group resource has a single type having the same resource type or a mixed type having different types.

When the member type attribute information is set to single, the M2M device checks whether or not the connection is available for non-connectable member identification information (S1330). If it is determined that connectable member identification information is connectable, the value of the memberTypeValidated attribute information Is set to TRUE (S1345). Thereafter, the M2M device sets an identifier indicating that the group resource processing operation according to the request message is successful as a response status code (S1350). In this case, if the member resource that has been temporarily unavailable is changed to be connectable, the entire member requested by the high caller is confirmed to be connectable, and the process for the group resource is successful, so that the same response status code as S1255 can be set .

On the other hand, if it is determined that the non-connectable member identification information is still unreachable, the M2M device checks the value of the enforcement attribute information for the group resource included in the request message (S1335). The Enforcement attribute information includes information indicating whether or not to perform a processing operation on the requested group resource even when an unavailable member exists.

For example, when the Enforcement attribute information is set to TRUE, the M2M apparatus performs a processing operation on the group resource even if an unavailable member exists, sets a response status code as an identifier indicating that the processing operation has been successfully performed, (S1320). However, in this case, as described above, the member identification information that can not be connected to the unreachableMemberIDs attribute information of the group resource is stored, and only the member identification information that can be connected to the memberIDs attribute information is stored and managed separately. In the currentNrOfMembers attribute information, only the number of the member identification information included in the memberIDs attribute information can be counted and the corresponding value can be stored.

As another example, when the Enforcement attribute information is set to FALSE, the M2M device generates and sets a response status code indicating that the group resource processing operation according to the request message fails (S1340). If necessary, the M2M device may perform the operation of step S1330 to again check whether or not connection to the non-connectable member is possible.

On the other hand, if the member type attribute information is set to be mixed, the M2M device checks whether or not the connection is available for non-connectable member identification information (S1355). If it is determined that the non-connectable member identification information is connectable, Is set to TRUE (S1360). Thereafter, the M2M device sets an identifier indicating that the group resource processing operation according to the request message is successful as a response status code (S1360). In this case, if the member resource that was temporarily unavailable is changed to be connectable, the entire member requested by the high caller is confirmed to be connectable, and the processing of the group resource is successful. Therefore, the same response status code as S1255 and S1350 is set .

On the other hand, if it is determined that the non-connectable member identification information is still unreachable, the M2M device checks the value of the enforcement attribute information for the group resource included in the request message (S1370). The Enforcement attribute information includes information indicating whether or not to perform a processing operation on the requested group resource even when an unavailable member exists.

For example, when the Enforcement attribute information is set to TRUE, the M2M device performs a processing operation on the group resource even if a non-connectable member exists, and sets the response status code as an identifier indicating that the processing operation has been successfully performed as a mixed type (S1375). However, in this case, as described above, the member identification information that can not be connected to the unreachableMemberIDs attribute information of the group resource is stored, and only the member identification information that can be connected to the memberIDs attribute information is stored and managed separately. In the currentNrOfMembers attribute information, only the number of the member identification information included in the memberIDs attribute information can be counted and the corresponding value can be stored.

As another example, when the Enforcement attribute information is set to FALSE, the M2M device generates and sets a response status code indicating that the group resource processing operation according to the request message fails (S1380). The response status code in this case can be set to the same value as the response status code in S1340. If necessary, the M2M device may perform the operation of step S1355 to again check whether or not connection to the non-connectable member is possible.

As described above, the sender can confirm various situations according to the group resource processing request through different response status codes, and the receiver can more clearly manage the group resources by using the unreachableMemberIDs and the Enforcement attribute information on the group resources . In addition, the sender can prevent the occurrence of problems by preliminarily grasping possible problems in the control of the group resources through additional measures by using the unreachableMemberIDs and the Enforcement attribute information of the group resources.

FIG. 14 is a diagram for explaining a type of a response status code indicating a success process according to an embodiment.

Referring to FIG. 14, there may be various types of successful request message processing successes in the contexts of FIGS. 12 and 13. Therefore, it is necessary to add a response status code according to the kind of processing success to the conventional response status code.

For example, in the past, 2000 response status codes could be set when the processing of the request message was successful, and 2001, 2002, 2004 could be set according to generation, deletion, and update, respectively. Additionally, in the present disclosure, a response status code indicating SUCCESSFUL_OPERATION_GROUP_RESOURCE for step S1320 may be added. Also, in the present disclosure, a response status code indicating SUCCESSFUL_MIXED_GROUP_RESOURCE for step S1375 may be added. Each status code is 20XX, the code value can be determined by the setting between the sender and the receiver, and the two additional code values are set differently.

15 is a diagram for explaining a type of a response status code indicating failure processing according to an embodiment.

Referring to FIG. 15, as in FIG. 14, the response status code can be set differently even if the processing of the request message fails. For example, three response status codes, which are set to 52XX in response status codes for existing processing failures, can additionally be set according to the processing types in FIGS. 12 and 13. [ The three additional response status codes are set to different code values.

As shown in FIGS. 14 and 15, by adding the response status code, the sender can more variously confirm the type of the processing failure or the processing success of the request message, and can be utilized for additional requests or control thereafter.

FIG. 16 is a diagram illustrating a configuration of a group resource according to an exemplary embodiment.

Referring to FIG. 16, it is necessary to define additional attribute information for a conventional group resource in order to efficiently utilize the above-described request message processing operation.

For example, the group resource may include current member count information, connectable member identification information, and non-connectable member identification information, and the current member count information may be set in association with the number of connectable member identification information . Also, it may include attribute information on the execution direction information.

As described above, the unconnectable member identification information is included in the unreachableMemberIDs attribute information 1600, and the enforcement indication information may be included in the Enforcement attribute information 1610. [ The unreachableMemberIDs attribute information 1600 may store the identification information of the corresponding member in a list format when the M2M device receiving the request message temporarily or permanently disables the connection. In addition, the Enforcement attribute information 1610 may include information indicating whether to perform group resource processing when a caller can not access some of the members to be included in the group resource. For example, the Enforcement property information 1610 may be set to TRUE or FALSE.

On the other hand, the M2M device can store the corresponding value by counting only the number of member identification information included in the memberIDs attribute information that stores the identification information on the members connectable to the currentNrOfMembers attribute information.

In addition, as shown in FIG. 16, the group resource may include an attached resource in the conventional attribute information.

FIG. 17 is a view for explaining attribute information of a group resource according to an embodiment, and FIG. 18 is a view for explaining resource specific attributes of a group resource according to an embodiment.

17 and 18, the information to be included in the attribute information of each attribute information included in the group resource can be specifically set, the attribute information can be included in the request message, and the data type and the default value are determined .

Hereinafter, an example of primitive content for group resources stored and managed through the above-described operation will be described with reference to the drawings.

19 is a view for explaining a problem of primitive content of group resources according to the related art.

Referring to FIG. 19, the primitive content of the group resource may include various attribute information. For example, pc means Primitive Content and m2m: grp means group resource in M2M system. ri is Resource ID, rn is Resource Name, pi is Parent ID, et is Expiration Time, ct is Creation Time, and lt is Last Modified Time. The value of each attribute information is described for example.

Mt is the Member Type, cnm is the Current Number of Members, mnm is the Max Number of Members, mid is the Member IDs, csy is the Consistency Strategy, and fopt is <fanOutPoint>.

For example, the cnm information means the number of group members included in the group resource, which means that five CSE containers are created as one group. mnm means a group member in the maximum group resource, and is set to 6, for example. Also, csy is set to 1 and is set to ABANDON_MEMBER. However, when the receiving end generates group resources according to the sender's group resource creation request message, the containers of CSE1 to CSE3 respond to the request of the receiving end and can be connected to the receiving end, or CSE4 and CSE5, It can be an unrecooked member that can not be connected to the receiving end like an error. According to the related art, the receiving end generates five groups of containers, CSE1 to CSE5, even if unrecognized unreachable members are included, sets a response status code indicating success of generation, and sends the response message to the sender there was.

In this case, the sender can not confirm the information that CSE 4 and 5 are unrecognized members, and there is a possibility that the five group members are mistakenly created as a group resource normally. In addition, there is no way for the receiving end to excessively repeat the connection to the non-connectable member or to check that the connection is impossible, which may cause a problem in unnecessary wireless system overload occurrence and normal request processing.

Meanwhile, in the prior art not applying the present embodiment, when a sender requests a fanout, a problem may arise in a procedure for processing the fanout. For example, a sender can request a fanout to the receiving end using the Group Request Target Members parameter. However, in the prior art in which the receiving end does not separately manage the inaccessible member, the receiving end does not know the fanout target member pointed by the Group Request Target Members parameter and thus fails to process the request of the sender, There was a problem of handling fanout members.

20 is a diagram illustrating exemplary primitive content of a group resource according to an exemplary embodiment of the present invention.

Referring to FIG. 20, it is shown that the above-described problem can be solved through the present embodiment. For example, the M2M device can check whether or not a connection to a member of the group resource is available, and if there is a member that can not be connected, it can be separately stored and managed in the unreachableMemberIDs attribute information. That is, "CSE4 / contaner" and "CSE5 / contaner" group resource members can manage connection state through separate attribute information.

In this case, only the identification information of the members that can be connected to the mid attribute information can be managed in a list format. Also, the cnm attribute information may be stored and managed by changing the number of connectable member identification information as needed.

Through this, the M2M device and the caller can confirm and manage accurate information on the group resource, thereby preventing an error occurrence and an unexpected uncontrollable situation.

Further, the receiving end manages the unreachableMemberIDs as separate attribute information, and when the group resource is generated, it is indicated in the response status code that there is a member that can not be accessed, and the result is transmitted to the caller. A target action request for a member is possible.

Meanwhile, the consistencyStrategy (csy) among the attribute information of the group resource may be set differently from the conventional one.

FIG. 21 is a view for explaining values included in consistencyStrategy attribute information according to an embodiment.

Referring to FIG. 21, for example, the member type (mt) information and the current member count (cnm) and csy information may not coincide with each other in the sender's group resource processing request message. For example, CSEs 1 to 5, which are requested by the sender to create a group resource, are all container resources, and csy is set to 3, which is set as a mixed type, and a request message for requesting generation of a group resource may be received.

In this case, it is difficult for the receiving end to determine whether the csy is erroneous or the target members requesting the group resource are wrong. Thus, how the receiving end should create the group resource can be a problem. In addition, the caller requests to create groups of different types of members in a state where all the members included in the group resource can not be connected, but members of group resources created only for the actually connectable members may be the same type . In this case, since csy is not a mixed type, a processing problem may occur.

In order to solve this problem, the present disclosure defines that additional values can be set in csy. For example, HOSTING_CSE_DECISION may be assigned to csy information 4 to allow the receiving end to determine and process a mismatch error in a request related to the group resource processing of the sender. That is, when the HOSTING_CSE_DECISION is indicated by csy, the receiving end can determine and process the collided part in the sender's request message itself.

In this case, a separate response status code may be set to inform the caller of the processing result.

In the above, the case where the caller requests the group resource processing is described as an example of requesting the group resource processing. However, as described at the beginning, the embodiments can be applied to all group resource processing operations including generation and update of group resources, inquiry, deletion, and notification.

Hereinafter, the case where the request message requests the update of the group resource is briefly described again, and the operations described above can be equally applied to generation or update.

For example, in a case where a request message for requesting update of a group resource is received, if the above-mentioned non-connectable member occurs, the receiving end can modify and manage the attribute information and the contents of the parameter. That is, when the addition or change of a member to a specific group resource is requested through an update operation, the M2M device of the receiving end confirms whether or not the member to which addition or modification is requested is connectable, and the unreachableMemberIDs attribute Information is separately stored and managed. In addition, a response status code indicating the processing result for this can be set and transmitted to the caller.

In this way, even when the request message indicates update, it can be managed in the same form using the additional attribute information of the group resource.

Meanwhile, the identification (ID) information included in the unreachableMemberIDs attribute information may be changed from time to time. Thus, a method may be needed to maintain the identity of the unreachableMemberIDs in the M2M device.

For this, the following method can be used.

The member identification information of a group resource is a list of member resource IDs that exist in the CSEBase, AE, or remoteCSE subclass (A memberIDs for <group> resource is a list of member IDs which exist under CSEBase, AE or remoteCSE. The <remoteCSE> and <AE> resources have requestReachability attribute information (The <remoteCSE> and <AE> resources have specified requestReachability attribute).

Therefore, the resource for the memberID attribute information can provide the stem resource as connectability information of the <remoteCSE> or <AE> resource for the Hosting CSE of the group resource (for any resource for memberIDs can provide the reachability information of <remoteCSE > or <AE> resource form the stem resource to Hosting CSE of <group> resource).

The Hosting CSE of the group resource can obtain accessibility information through subscription. That is, the Hostong CSE of the group resource subscribes to the <remoteCSE> or <AE> resources of each memberID (A Hosting CSE of <group> resource get reachability information by subscription ie the Hostong CSE of <group> resource subscribes <remoteCSE> or <AE> resource of each memberIDs).

Meanwhile, the notificationURI attribute information of the subscription resource is a group resource (the notification resource attribute of the <subscription> resource is <group> resource). The CSE hosting of the group resource can extract the connectivity information from the subscription result notification that will update the connectivity information (Hosting CSE of <group> resource extracts reachability information which will be updated information of reachability).

This makes it possible to cope with the case where the list in the unreachableMemberIDs attribute information is changed occasionally.

As described above, according to the present embodiment, the M2M device provides the effect of enabling stable M2M system operation by eliminating the possibility of error occurrence by using newly added attribute information in processing group resources.

Hereinafter, the configuration of the M2M device capable of performing all of the embodiments described with reference to Figs. 1 to 21 will be described once again with reference to the drawings.

22 is a view for explaining an M2M device according to an embodiment.

22, the M2M apparatus 2200 includes a receiving unit 2230 that receives a request message for requesting a processing operation of a group resource, and a receiving unit 2230 that determines whether or not each member can be connected based on at least one member identification information included in the group resource A control unit 2210 for generating response status code information based on at least one of the connection availability result and information included in the request message, and a transmission unit for transmitting a response message including response status code information for the request message 2220).

For example, the receiving unit 2230 may receive a request message requesting generation or update of a group resource from another M2M device or a node of another M2M system. The request message may include at least one of member type information, current member count information, maximum member count information, at least one member identification information, consistency strategy information, and execution instruction information.

The control unit 2210 performs a requested processing operation on the group resource using parameters and attribute information included in the request message.

For example, the control unit 2210 can confirm whether or not the connection to each of the members to be included in the group resource is possible. In order to confirm whether or not the connection can be made, the control unit 2210 can confirm whether or not the resource of the corresponding member identification information can be accessed by using the member identification information of each member.

The control unit 2210 may perform the request processing operation according to the connection availability result and generate the response status code information.

For example, if it is determined that all of the one or more member identification information included in the group resource can be accessed, the control unit 2210 generates or updates the group resource according to the group operation type of the group resource, As an identifier for instructing the user.

In another example, when the control unit 2210 determines that at least one member identification information of the at least one member identification information included in the group resource is inaccessible, the control unit 2210 processes the attribute information of the group resource so that the member identification information, The response status code can be generated by setting it as an identifier indicating success in processing. For example, when the connection to some members to be included in the group resource is impossible, the M2M device generates the group resource including the member to be included in the group resource, and stores the member identification information in the separate attribute information Group resources can be created.

As another example, if it is determined that at least one member identification information among the one or more member identification information included in the group resource is inaccessible, the control unit 2210 further uses the consistency strategy information included in the request message, Perform processing operations based on the set values, and generate response status codes.

For example, when the consistency strategy information is set as the member excluded, the control unit 2210 determines that the group resource includes only the remaining member identification information excluding the member identification information that is determined to be inaccessible among the at least one member identification information included in the group resource And sets the response status code to an identifier indicating the success of the processing.

As another example, when the consistency strategy information is set to group excluded, the control unit 2210 can generate a response status code by setting the response status code as an identifier indicating failure in processing.

As another example, when the consistency strategy information is set to a mixed (or composite), the control unit 2210 further confirms the member type information included in the request message, and in response to the value of the confirmed member type information, Status codes can be set separately.

As another example, when the consistency strategy information is set to be mixed, the control unit 2210 can set the response status code by dividing the response status code into an identifier indicating success or failure of processing according to the value of the execution direction information included in the request message.

Meanwhile, the transmitter 2220 transmits a response message including a response status code indicating a result of the request operation, which is indicated by the request message, to the sender when the process success or the process failure is finally determined.

As described above, the response status codes are set to be distinguished from each other according to the result of each processing operation, so that the sender can confirm the processing result in more detail. Meanwhile, the response message includes the same request identifier as the request message, and may include a response status code.

In addition, the control unit 2210 generally controls the operation of the M2M device necessary for the operation of processing the group resources according to the present embodiment. The transmitting unit 2220 and the receiving unit 2230 can exchange data, information, and signals according to the present embodiment with other M2M devices, nodes, applications, and the like.

The standard content or standard documents referred to in the above-mentioned embodiments constitute a part of this specification, for the sake of simplicity of description of the specification. Therefore, it is to be understood that the content of the above standard content and portions of the standard documents are added to or contained in the scope of the present invention.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

Claims (21)

A method of processing a group resource by a machine-to-machine communication (M2M)
Receiving a request message requesting a group resource processing operation;
Confirming whether or not each member is connectable based on at least one member identification information included in the group resource;
Generating the response status code information based on at least one of the connection confirmation result and the information included in the request message; And
And sending a response message including the response status code information for the request message. The method according to claim 1,
The request message includes:
Member type information, current member count information, maximum member count information, at least one member identification information, consistency strategy information, and execution instruction information. 3. The method of claim 2,
Before the step of confirming the connection availability,
Comparing the current member count information and the maximum member count information,
And stops the processing of the group resource when the current number of members exceeds the maximum number of members. The method according to claim 1,
Wherein the group resource comprises:
The current member count information, the connectable member identification information, and the non-connectable member identification information,
Wherein the current member number information is set in association with the number of connectable member identification information. The method according to claim 1,
The step of generating the response status code information comprises:
And if it is determined that all of the one or more member identification information included in the group resource can be accessed, generating or updating the group resource according to a type of the group resource operation,
And setting the response status code as an identifier indicating a success of the processing. The method according to claim 1,
The step of generating the response status code information comprises:
If the at least one member identification information of the at least one member identification information included in the group resource is determined to be inaccessible, processing is performed so that the inaccessible member identification information is included in the attribute information of the group resource,
And setting the response status code as an identifier indicating a success of the processing. The method according to claim 1,
The step of generating the response status code information comprises:
And generating the response status code information based on the value set in the consistency strategy information included in the request message if at least one member identification information included in the group resource is determined to be inaccessible Lt; / RTI &gt; 8. The method of claim 7,
The step of generating the response status code information comprises:
Processing the group resource so that only the remaining member identification information other than the member identification information that is determined to be inaccessible among the at least one member identification information included in the group resource is included when the consistency strategy information is set as member exclusion,
And setting the response status code as an identifier indicating a success of the processing. 8. The method of claim 7,
The step of generating the response status code information comprises:
And generating the response status code as an identifier indicating failure in processing if the consistency strategy information is set to group excluded. 8. The method of claim 7,
The step of generating the response status code information comprises:
Further comprising the step of confirming the member type information included in the request message when the consistency strategy information is set to be mixed,
Wherein the response status code indicating the success of the process is identified and set according to the value of the member type information. 8. The method of claim 7,
The step of generating the response status code information comprises:
If the consistency strategy information is set to be mixed, the response status code is divided into identifiers indicating success or failure of processing according to the value of the execution indication information included in the request message. 1. A machine-to-machine communication (M2M) apparatus for processing group resources,
A receiving unit for receiving a request message requesting a group resource processing operation;
Confirms whether or not each member can be connected based on one or more member identification information included in the group resource,
A control unit for generating the response status code information based on at least one of the connection confirmation result and the information included in the request message; And
And a transmitter for transmitting a response message including the response status code information for the request message. 13. The method of claim 12,
Wherein,
Compares the current member number information and the maximum member number information included in the request message, and stops the group resource processing operation when the current member number exceeds the maximum number of members. 13. The method of claim 12,
Wherein the group resource comprises:
The current member count information, the connectable member identification information, and the non-connectable member identification information,
Wherein the current member number information is set in conjunction with the number of connectable member identification information. 13. The method of claim 12,
Wherein,
And if it is determined that all of the one or more member identification information included in the group resource can be accessed, generating or updating the group resource according to a type of the group resource operation,
And generates the response status code by setting the response status code as an identifier indicating success of the process. 13. The method of claim 12,
Wherein,
If the at least one member identification information of the at least one member identification information included in the group resource is determined to be inaccessible, processing is performed so that the inaccessible member identification information is included in the attribute information of the group resource,
And generates the response status code by setting the response status code as an identifier indicating success of the process. 13. The method of claim 12,
Wherein,
And generating the response status code information based on the value set in the consistency strategy information included in the request message if at least one member identification information included in the group resource is determined to be inaccessible M2M device characterized by. 18. The method of claim 17,
Wherein,
Processing the group resource so that only the remaining member identification information other than the member identification information that is determined to be inaccessible among the at least one member identification information included in the group resource is included when the consistency strategy information is set as member exclusion,
And generates the response status code by setting the response status code as an identifier indicating success of the process. 18. The method of claim 17,
Wherein,
And generates the response status code by setting the response status code as an identifier indicating failure in processing when the consistency strategy information is set as the group exclusion. 18. The method of claim 17,
Wherein,
If the consistency strategy information is set to be mixed, confirms the member type information included in the request message,
And sets the response status code indicating the success of the processing according to the value of the member type information. 18. The method of claim 17,
Wherein,
When the consistency strategy information is set to be mixed, the response status code is divided into identifiers indicating success or failure of processing according to values of the execution indication information included in the request message.

Images